小菜鸟

MyBatis 逆向工程全指南：从配置到高级定制（含 IDEA 实战与避坑）

MyBatis 逆向工程（MyBatis Generator，简称 MBG）是 MyBatis 官方提供的代码生成工具，可根据数据库表自动生成 实体类、Mapper 接口、Mapper XML 文件，大幅减少重复的 CRUD 代码编写工作。 依赖优化、高级配置（如分页 / 注释 / 逻辑删除）、IDEA 快捷配置、常见问题解决方案 及 工程化最佳实践，帮助你高效落地逆向工程。

逆向工程核心依赖与版本选型

1. Maven 依赖配置

<dependencies>
    <!-- MyBatis 核心依赖 -->
    <dependency>
        <groupId>org.mybatis</groupId>
        <artifactId>mybatis</artifactId>
        <version>3.5.16</version>
    </dependency>

    <!-- MyBatis 逆向工程核心包 -->
    <dependency>
        <groupId>org.mybatis.generator</groupId>
        <artifactId>mybatis-generator-core</artifactId>
        <version>1.4.2</version> <!-- 最新稳定版，修复旧版bug -->
        <scope>provided</scope> <!-- 仅编译期使用，避免打包到生产环境 -->
    </dependency>

    <!-- MySQL 驱动（需与数据库版本匹配，8.0+用8.x版本） -->
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>8.0.33</version>
        <scope>runtime</scope>
    </dependency>

    <!-- 日志依赖（便于查看逆向工程执行日志，可选） -->
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-api</artifactId>
        <version>1.7.36</version>
    </dependency>
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-simple</artifactId>
        <version>1.7.36</version>
        <scope>test</scope>
    </dependency>
</dependencies>

<!-- 可选：配置 Maven 插件，通过命令行执行逆向工程 -->
<build>
    <plugins>
        <plugin>
            <groupId>org.mybatis.generator</groupId>
            <artifactId>mybatis-generator-maven-plugin</artifactId>
            <version>1.4.2</version>
            <configuration>
                <!-- 逆向工程配置文件路径 -->
                <configurationFile>src/main/resources/generatorConfig.xml</configurationFile>
                <!-- 执行后是否覆盖已有文件（建议开发期设为true） -->
                <overwrite>true</overwrite>
                <!-- 打印执行日志 -->
                <verbose>true</verbose>
            </configuration>
            <dependencies>
                <!-- 插件依赖的数据库驱动（避免版本冲突） -->
                <dependency>
                    <groupId>mysql</groupId>
                    <artifactId>mysql-connector-java</artifactId>
                    <version>8.0.33</version>
                </dependency>
            </dependencies>
        </plugin>
    </plugins>
</build>

逆向工程配置文件深度解析

1. 完整配置文件（generatorConfig.xml）

Spring Security 核心过滤器详解：过滤器链的工作机制与职责分工

Spring Security 的本质是一个过滤器链，所有 Web 安全功能（认证、授权、CSRF 防护等）均通过不同职责的过滤器协同实现。每个过滤器专注于单一功能，按特定顺序组成链，确保请求在到达业务代码前完成安全校验。从 “职责定义→工作流程→关键源码→使用场景” 四个维度，彻底讲透每个过滤器的作用与协作逻辑。

过滤器链的整体执行顺序

在分析单个过滤器前，需先明确过滤器链的默认执行顺序（Spring Security 自动维护，顺序不可随意调整），这是理解安全流程的基础：

注：实际项目中可能存在更多过滤器（如 RememberMeAuthenticationFilter、OAuth2 相关过滤器），但上述 8 个是最核心的基础过滤器。

核心过滤器详解

1. SecurityContextPersistenceFilter：安全上下文的 “管家”

核心职责：在请求开始时创建 SecurityContext（存储用户认证信息），在请求结束时清空 SecurityContextHolder（避免 ThreadLocal 内存泄漏），是整个安全流程的 “基础保障”。

工作流程

1. 请求到达时：
   • 从 HttpSession 中读取 SecurityContext（若存在，说明用户已登录）；
   • 若不存在，创建新的 SecurityContext；
   • 将 SecurityContext 存入 SecurityContextHolder（ThreadLocal 存储，供后续过滤器使用）。
2. 请求结束时：
   • 若 SecurityContext 有变化（如用户刚登录），将其写入 HttpSession；
   • 调用 SecurityContextHolder.clearContext()，清空当前线程的 SecurityContext。

关键源码

红黑树：自平衡二叉查找树的高效实现

红黑树是一种自平衡的二叉查找树，通过一套特定的规则（颜色约束和旋转操作）保证树的高度始终维持在O(logn)级别，解决了普通二叉查找树在极端情况下退化为链表（查询效率降至O(n)）的问题。它广泛应用于 Java 的TreeMap、C++ 的map等集合类，以及数据库索引的底层实现。

二叉查找树的局限性与红黑树的诞生

二叉查找树的核心特性

二叉查找树（BST）满足：

• 左子树所有节点值 < 根节点值；
• 右子树所有节点值 > 根节点值；
• 左右子树均为二叉查找树。

其查询、插入、删除的平均时间复杂度为O(logn)，但在有序插入时（如依次插入 1,2,3,4），会退化为单链表，此时操作复杂度飙升至O(n)。

根据二分查找树的特性来说，使用中序遍历可以得到一个由小到大的有序序列。

插入节点

Hive 分组拼接：collect_set + concat_ws，替代 MySQL 的 group_concat

在 MySQL 里，group_concat 是一个很常用的函数——按某个字段分组，把组内另一个字段的值用逗号拼成一行。

比如：

SELECT doc_id, GROUP_CONCAT(name) FROM table GROUP BY doc_id;

结果可能是：

doc_001 | 分类1,分类2,分类3

但 Hive 里没有 group_concat。

Hive 的替代方案是两步走：

1. collect_set / collect_list：把同组的多行聚合成一个数组
2. concat_ws：把数组用分隔符拼成字符串

concat_ws(',', collect_set(列名))  -- 相当于 group_concat

两个函数的分工

组合方式：

concat_ws(',', collect_set(列名))   -- 去重拼接
concat_ws(',', collect_list(列名))  -- 不去重拼接

一个实际的例子：文档的分类拼接

需求： 有一张文档分类关联表，一个文档可以属于多个分类。现在要按 doc_id 分组，把每个文档的所有分类名称拼成一行。

数据：

SQL（去重拼接）：

SYN Flood 攻击：原理、危害与防御机制

SYN Flood 攻击是一种针对 TCP 协议缺陷的经典 DoS（拒绝服务）攻击，通过耗尽服务器的连接资源，导致正常用户无法建立连接。其核心原理利用了 TCP 三次握手的机制漏洞，尤其是服务器对未完成连接的超时处理机制。以下从攻击原理、危害到防御措施展开详细解析。

SYN 超时重试：攻击的 “突破口”

TCP 三次握手过程中，若服务器发送 SYN-ACK 后未收到客户端的 ACK（第三次握手），会触发SYN 超时重试机制，这一机制成为 SYN Flood 攻击的关键目标。

超时重试流程：

1. 服务器收到客户端的 SYN 请求，回复 SYN-ACK 后进入SYN_RECV状态，同时将该连接放入SYN 队列（半连接队列）。
2. 若客户端未回复 ACK（如客户端掉线、恶意不回复），服务器会周期性重发 SYN-ACK：
   • 默认重试5 次，间隔时间呈指数递增（1s → 2s → 4s → 8s → 16s）。
   • 第五次重发后，服务器需等待 32s 确认超时，总耗时 63s后才会从 SYN 队列中移除该连接。

风险点：

• 服务器的 SYN 队列容量有限（默认通常为几百至几千）。
• 若大量未完成的连接占用 SYN 队列，新的正常连接请求会因队列满而被拒绝，导致服务器 “拒绝服务”。

SYN Flood 攻击：利用漏洞的恶意行为

SYN Flood 攻击正是利用了上述超时重试机制，通过伪造大量虚假的 SYN 请求，耗尽服务器的 SYN 队列资源，使正常连接无法建立。

攻击过程：

1. 攻击者向目标服务器发送大量伪造源 IP 的 SYN 请求（源 IP 可能不存在或不可达）。
2. 服务器收到 SYN 后，回复 SYN-ACK，但由于源 IP 虚假，永远收不到 ACK，连接被放入 SYN 队列并等待超时。
3. 随着虚假连接不断增加，SYN 队列很快被占满，服务器无法处理新的正常 SYN 请求，导致合法用户无法建立 TCP 连接。