企业官网建设流程全解析

1. 为什么今天还要认真学 Druid？不是所有连接池都叫“生产级”

你打开一个 Spring Boot 项目，application.yml里随手写上spring.datasource.type=com.alibaba.druid.pool.DruidDataSource，然后加个druid-spring-boot-starter依赖——这操作太熟了，熟到很多人以为“配上了就是会用了”。但去年我帮某金融类 SaaS 系统做压测复盘时发现：他们线上数据库平均连接等待时间高达 427ms，高峰期超时告警频发，而监控显示 Druid 的 activeCount 常年卡在 28～30（maxActive=30），但实际业务 QPS 才 180。排查三天后真相是：Druid 被当成了“高级 HikariCP”在用——只启用了基础连接管理，却完全没开启它的核心防御能力。这不是配置错误，而是对 Druid 的本质认知偏差。

Druid 不是一个“带监控页面的连接池”，它是一套嵌入式数据库访问中间件。它的设计哲学很明确：在连接池之上，叠加连接生命周期治理、SQL 行为审计、运行时风险拦截、多维指标透出四大能力层。HikariCP 解决的是“怎么更快地借还连接”，Druid 解决的是“借出去的连接有没有被滥用、还回来的连接是否健康、谁在偷偷执行慢 SQL、系统快崩了能不能自动熔断”。这就像同样是汽车，HikariCP 是高性能发动机，Druid 则是带主动刹车、胎压监测、黑匣子和远程诊断的智能底盘系统。

所以当你看到“druid数据库连接池的使用”这个标题，别只想着怎么把urlusernamepassword填对。真正要拆解的是：如何让 Druid 在你的系统里从“可用”走向“可控”、“可溯”、“可防”、“可调”。它适合三类人深度阅读：一是正在接手老项目、发现数据库偶发超时却无从下手的后端工程师；二是负责中间件选型、需要对比连接池真实防护能力的技术负责人；三是刚学完 JDBC、想理解“连接池到底在底层干了什么”的进阶学习者。接下来的内容，不讲 API 列表，不贴默认配置，只聚焦一个目标：让你第一次配置 Druid 时，就避开 90% 的线上事故诱因。

2. 架构设计逻辑：为什么 Druid 的配置项多得像路由器说明书？

2.1 它不是“连接池+监控”，而是“连接池×治理引擎”

很多初学者翻 Druid 文档，看到几十个配置项直接头皮发麻。其实只要抓住一条主线：Druid 的所有配置，都在回答三个问题——连接怎么来、SQL 怎么管、风险怎么拦。它把传统连接池的单点功能，拆解成三层协同模块：

• 连接管理层（Connection Management）：负责物理连接的创建、验证、回收、保活。对应initialSize、minIdle、maxActive、validationQuery、testWhileIdle等。
• SQL 治理层（SQL Governance）：对每条执行的 SQL 进行解析、过滤、统计、采样。对应wallFilter、statFilter、slf4jFilter、connectionProperties中的druid.stat.mergeSql=true等。
• 运行时防护层（Runtime Protection）：在连接池运行过程中动态干预异常行为。对应removeAbandonedOnBorrow、removeAbandonedOnMaintenance、phyTimeoutMillis、failFast、maxWait等熔断与降级参数。

这三层不是并列关系，而是嵌套调用：每次getConnection()时，先走连接管理层拿连接；拿到连接后，SQL 治理层会拦截PreparedStatement.execute()；而当连接长时间未归还或检测到异常，运行时防护层会触发清理或告警。这种设计导致它的配置项天然比 HikariCP 多——因为你在配的不是一个池子，而是一整套数据库访问治理体系。

提示：不要试图一次性配全所有参数。生产环境上线前，必须按优先级分三批配置：第一批次（必开）解决连接泄漏与死锁，第二批次（强推）解决 SQL 注入与慢 SQL 发现，第三批次（按需）解决定制化审计与熔断策略。后面会逐批详解。

2.2 为什么它敢把 SQL 解析器塞进连接池？

这是 Druid 最被低估的硬核能力。绝大多数连接池（包括 HikariCP、DBCP2）对 SQL 是“零感知”的——它们只管连接，不管 SQL 长什么样。而 Druid 内置了轻量级 SQL 解析器（基于 JSQLParser 改造），能在PreparedStatement创建时就解析出 SQL 类型（SELECT/UPDATE/INSERT）、表名、参数个数、是否含子查询等元信息。这个能力直接支撑了三大关键功能：

• SQL 合并统计（mergeSql）：把SELECT * FROM user WHERE id = ?和SELECT * FROM user WHERE id = ?归为同一类 SQL，避免监控页面被千奇百怪的占位符刷屏；
• WallFilter 防注入：识别SELECT * FROM user WHERE name = 'a' OR '1'='1'这类非法逻辑，直接抛SQLException；
• 慢 SQL 自动采样：当executeQuery()耗时超过slowSqlMillis，自动记录完整 SQL 文本、执行堆栈、绑定参数值。

这个设计的代价是：每个 PreparedStatement 创建时会有约 0.03ms 的解析开销。听起来微不足道，但在 QPS 5000+ 的 OLTP 场景下，每天可能多消耗 12 万次解析。所以 Druid 提供了notFullAuditEnable=false（默认 true）开关，关闭全量解析，只对 SELECT/UPDATE/INSERT/DELETE 四类主语句解析。实测下来，在电商订单查询场景中，开启全解析会使 CPU 使用率上升 1.2%，但换来的是 100% 的 SQL 注入拦截率和精准的慢 SQL 定位能力——这笔账，值得算。

2.3 监控不是“锦上添花”，而是“故障定位的唯一入口”

Druid 的/druid/index.html页面常被吐槽“丑”，但它解决了一个致命问题：当数据库响应变慢时，你不需要登录服务器查日志、不需要连数据库看 processlist、不需要重启应用——所有关键线索都在这个页面里实时滚动。它的监控数据不是采样上报，而是内存内实时聚合，延迟低于 2 秒。页面左侧的“SQL 监控”能直接看到：

• 当前最耗时的 10 条 SQL（含完整文本、执行次数、平均毫秒、最大毫秒）；
• 每条 SQL 对应的 Java 调用栈（精确到OrderService.java:142）；
• 绑定参数的实际值（比如? = 'admin@xxx.com'）；
• 是否命中了 WallFilter 规则（标红提示“违反白名单表”）。

而右侧的“数据源”面板则展示：

• activeCount（当前活跃连接数） vs. poolingCount（空闲连接数）的实时曲线；
• executeCount（总执行次数）与commitCount（事务提交次数）的比值，若长期 > 3，说明大量非事务性查询未显式关闭连接；
• discardCount（被丢弃连接数），一旦非零，立刻检查phyTimeoutMillis和removeAbandonedOnBorrow是否生效。

这些数据不是“看看而已”，而是故障定位的黄金线索。去年某支付系统凌晨 3 点出现数据库连接池打满，运维第一反应是扩容 RDS，而我打开 Druid 页面 10 秒就定位到：discardCount每分钟增长 12，且所有被丢弃连接的调用栈都指向同一个ReportGenerator类——原来是定时任务里忘了关ResultSet。这就是为什么我说：Druid 的监控页面不是附加功能，而是连接池的“CT 扫描仪”。

3. 核心配置与实操要点：从“能跑”到“稳如磐石”的七步法

3.1 第一步：基础连接管理——先堵住最危险的漏洞

很多线上事故，根源不是高并发，而是低并发下的连接泄漏。比如一个try-with-resources忘写close()，或者finally块里connection.close()抛了 NPE 导致未执行。Druid 提供了两道保险：

# application.yml spring: datasource: druid: # 【关键】连接空闲 5 分钟后自动校验有效性，避免网络闪断后连接变僵尸 test-while-idle: true time-between-eviction-runs-millis: 300000 validation-query: SELECT 1 # 【关键】借连接时强制校验，宁可慢一点，也不能借到坏连接 test-on-borrow: true # 【关键】连接最大空闲时间设为 30 分钟，避免长连接占用资源 min-evictable-idle-time-millis: 1800000 # 【关键】连接池初始大小设为 5，避免启动时瞬间创建大量连接冲击 DB initial-size: 5 min-idle: 5 max-active: 20

这里有个反直觉的点：test-on-borrow默认是 false。很多人觉得“每次借都校验太耗性能”，但实测表明，在 MySQL 8.0 + SSD 磁盘环境下，SELECT 1校验平均耗时 0.8ms，而一次连接泄漏导致的故障平均恢复时间是 23 分钟。用 0.8ms 换 23 分钟，这笔买卖永远划算。更关键的是，test-on-borrow能暴露底层驱动 bug——我们曾发现某国产数据库驱动在连接空闲 1 小时后，isValid()返回 true，但实际执行 SQL 会报Connection closed，正是靠这个参数提前捕获。

注意：validation-query的值必须是目标数据库支持的轻量查询。MySQL 用SELECT 1，Oracle 用SELECT 1 FROM DUAL，PostgreSQL 用SELECT 1。千万别写成SELECT NOW()，某些旧版驱动会因时区解析失败导致校验永远不通过。

3.2 第二步：SQL 治理层启用——让每条 SQL 都“可追溯、可拦截”

光有连接管理还不够。想象一个场景：前端传参id=1; DROP TABLE user; --，后端用String.format("SELECT * FROM user WHERE id = %s", id)拼 SQL，结果整个用户表被删。HikariCP 对此完全无感，而 Druid 可以在连接借出前就拦截。启用步骤分三步：

# 第一步：声明 Filter 链（顺序很重要！） filters: stat,wall,slf4j # 第二步：配置 WallFilter 白名单（防注入核心） connection-properties: druid.wall.white-list=127.0.0.1,192.168.10.0/24 druid.wall.db-type=mysql druid.wall.log-violation=true druid.wall.throw-exception=true # 第三步：开启 SQL 合并与慢 SQL 记录 druid: stat-view-servlet: enabled: true web-stat-filter: enabled: true filter: stat: merge-sql: true slow-sql-millis: 1000 log-slow-sql: true

这里的关键细节是filters的顺序：stat必须在wall前。因为statFilter 负责 SQL 解析和统计，wallFilter 依赖它解析出的 SQL 结构做规则匹配。如果顺序颠倒，wall会收到原始 SQL 字符串，无法识别参数化后的逻辑。

druid.wall.throw-exception=true是安全底线。它意味着一旦检测到非法 SQL（如UNION SELECT、EXEC、xp_cmdshell），直接抛SQLException，而不是默默记录日志。我们曾在线上灰度时关闭此开关，结果测试同学用id=1 OR 1=1成功绕过权限校验——这证明：日志记录是事后追责，异常抛出才是事前防御。

3.3 第三步：运行时防护——给连接池装上“自动刹车”

连接池打满的常见原因不是流量突增，而是个别慢查询或连接泄漏拖垮全局。Druid 的removeAbandoned系列参数就是为此而生：

# 当 borrow 连接超时，且 activeCount > maxActive * 0.8 时，强制回收 1 个最老的连接 remove-abandoned-on-borrow: true remove-abandoned-timeout: 1800 # 每 5 分钟扫描一次，回收空闲超 10 分钟的连接（防泄漏） remove-abandoned-on-maintenance: true time-between-eviction-runs-millis: 300000 min-evictable-idle-time-millis: 600000

注意remove-abandoned-timeout的单位是秒，不是毫秒！很多团队配成1800000（30 分钟），结果连接被误杀。合理值是 1800 秒（30 分钟）——足够覆盖最长事务，又不会误伤正常长事务。

更关键的是failFast参数：

# 开启后，当连接池为空时立即抛异常，而不是阻塞等待 maxWait fail-fast: true max-wait: 3000

这个组合拳的意义在于：让故障显性化。如果不开启failFast，当连接池耗尽时，线程会在take()上阻塞 3 秒，这 3 秒内线程无法处理新请求，导致请求堆积、线程池打满、最终服务雪崩。而开启后，第 1 个借不到连接的请求立刻失败，监控系统 5 秒内就能报警，运维能第一时间介入，而不是等到 3 分钟后看满屏 red alert。

3.4 第四步：监控与告警——把 Druid 页面变成“作战指挥室”

Druid 的监控页面默认路径/druid/index.html，但生产环境必须加访问控制。Spring Boot 下最简方案是：

@Configuration public class DruidConfig { @Bean public ServletWebServerFactory servletContainer() { TomcatServletWebServerFactory tomcat = new TomcatServletWebServerFactory(); tomcat.addAdditionalTomcatConnectors(redirectConnector()); return tomcat; } @Bean @ConditionalOnMissingBean public ServletWebServerFactory servletContainer() { TomcatServletWebServerFactory tomcat = new TomcatServletWebServerFactory(); tomcat.addAdditionalTomcatConnectors(redirectConnector()); return tomcat; } @Bean public ServletWebServerFactory servletContainer() { TomcatServletWebServerFactory tomcat = new TomcatServletWebServerFactory(); tomcat.addAdditionalTomcatConnectors(redirectConnector()); return tomcat; } // 此处省略重复代码，实际只需配置 WebStatFilter 和 StatViewServlet }

更推荐的做法是用 Spring Security 控制：

@Configuration public class SecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .antMatchers("/druid/**").hasRole("ADMIN") // 仅管理员可访问 .and().httpBasic(); // 启用基础认证 } }

然后在application.yml中配置账号密码：

spring: datasource: druid: stat-view-servlet: enabled: true url-pattern: /druid/* login-username: admin login-password: your_strong_password reset-enable: false # 生产环境禁用重置按钮

实操心得：我们给所有 Druid 监控页面统一加了企业微信机器人告警。当activeCount连续 3 分钟 >maxActive * 0.9，自动推送消息：“【紧急】订单库连接池使用率 92%，当前活跃连接 28/30，请检查慢 SQL 或连接泄漏”。这条规则上线后，连接池打满类故障平均响应时间从 17 分钟缩短到 92 秒。

3.5 第五步：JVM 层面适配——别让 GC 拖垮连接池

Druid 的连接对象（DruidPooledConnection）是重量级对象，内部持有Connection、Statement、ResultSet等原生资源。如果 JVM 配置不当，GC 会成为隐形杀手：

• 年轻代过小：DruidPooledConnection创建频繁，若Young GC频繁，会导致Eden区快速填满，触发Minor GC，而DruidPooledConnection大多存活期短，容易在Survivor区来回复制，浪费 CPU；
• 元空间不足：Druid 的 SQL 解析器会动态生成SQLSelectStatement等类，若MetaspaceSize过小，会触发Full GC；
• G1 停顿时间过长：G1 在混合回收阶段若MaxGCPauseMillis设为 200ms，而 Druid 的EvictTask（连接回收任务）执行时间波动大，可能被 GC 中断，导致连接清理延迟。

我们的生产环境 JVM 参数模板：

# -Xms4g -Xmx4g # 堆内存固定，避免动态伸缩抖动 -XX:+UseG1GC -XX:MaxGCPauseMillis=100 # G1 目标停顿时间设为 100ms，比默认 200ms 更激进 -XX:MetaspaceSize=256m # 元空间初始值，防止启动时频繁扩容 -XX:MaxMetaspaceSize=512m -Xmn1g # 年轻代 1G，确保 Eden 区足够大，减少 Minor GC 频率 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

实测对比：同样 2000 QPS 压测，用默认 JVM 参数时G1 Evacuation Pause平均耗时 186ms；调整后降至 63ms。这意味着 Druid 的连接回收任务能更及时执行，discardCount降低 72%。

3.6 第六步：多数据源场景——如何让 Druid 管理多个库而不混乱

微服务架构下，一个应用常连多个库（订单库、用户库、报表库）。此时不能简单复制多份DruidDataSourceBean，必须用DruidDataSourceFactory统一管理：

@Configuration public class MultiDataSourceConfig { @Bean(name = "orderDataSource") @ConfigurationProperties("spring.datasource.druid.order") public DataSource orderDataSource() { return DruidDataSourceFactory.createDataSource(); } @Bean(name = "userDataSource") @ConfigurationProperties("spring.datasource.druid.user") public DataSource userDataSource() { return DruidDataSourceFactory.createDataSource(); } }

对应的application.yml：

spring: datasource: druid: # 公共配置抽离 initial-size: 5 min-idle: 5 max-active: 20 test-while-idle: true time-between-eviction-runs-millis: 300000 validation-query: SELECT 1 # 订单库专属配置 order: url: jdbc:mysql://order-db:3306/order_db username: order_user password: xxx filters: stat,wall,slf4j connection-properties: druid.wall.db-type=mysql # 用户库专属配置 user: url: jdbc:mysql://user-db:3306/user_db username: user_user password: xxx filters: stat,wall,slf4j connection-properties: druid.wall.db-type=mysql

关键技巧：为每个数据源配置独立的stat-view-servlet路径，避免监控混淆：

spring: datasource: druid: order: stat-view-servlet: url-pattern: /druid/order/* user: stat-view-servlet: url-pattern: /druid/user/*

这样访问/druid/order/看订单库指标，/druid/user/看用户库指标，互不干扰。我们曾因没隔离路径，导致运营同学在用户库页面误点了“清空 SQL 记录”，结果订单库的慢 SQL 历史全没了——教训深刻。

3.7 第七步：升级与兼容性——别让版本升级变成线上事故

Druid 版本迭代极快，但1.2.16到1.2.18的升级曾让我们踩过大坑：1.2.18默认开启了druid.stat.mergeSql=true，而旧版监控页面不兼容新格式，导致/druid/sql.html页面白屏。解决方案不是回退，而是主动适配：

# 升级前必加（兼容旧监控页面） druid: filter: stat: merge-sql: false # 临时关闭，待前端适配后再开启

更隐蔽的坑在WallFilter：1.2.11之前，druid.wall.log-violation=true会记录所有被拦截的 SQL 到日志；1.2.11之后改为只记录throw-exception=true时的日志。如果你依赖日志做安全审计，升级后必须同步改配置。

我们的升级 checklist：

• ✅ 测试环境先跑 72 小时，重点观察discardCount、createErrorCount是否突增；
• ✅ 检查/druid/sql.html页面能否正常加载历史 SQL；
• ✅ 用curl -X POST "http://localhost:8080/druid/reset.html"清空监控数据，确认无 404；
• ✅ 压测验证maxWait超时行为是否符合预期（旧版超时抛SQLException，新版可能抛RuntimeException）；
• ✅ 更新druid-spring-boot-starter版本，确保与 Druid Core 版本匹配（如1.2.18对应1.2.18starter）。

4. 实操过程与核心环节实现：一次真实的生产环境接入全流程

4.1 场景还原：从零开始接入一个已上线的 Spring Boot 2.3 电商后台

系统现状：单体应用，MySQL 5.7，当前用 HikariCP，maxPoolSize=20，近期出现偶发Connection acquisition timed out报错，监控显示数据库 CPU 使用率峰值达 92%，但慢 SQL 日志里找不到明显问题。

第一步：引入依赖（Maven）

<dependency> <groupId>com.alibaba</groupId> <artifactId>druid-spring-boot-starter</artifactId> <version>1.2.18</version> </dependency> <!-- 注意：必须排除 HikariCP，否则两个连接池冲突 --> <exclusion> <groupId>com.zaxxer</groupId> <artifactId>HikariCP</artifactId> </exclusion>

第二步：基础配置（application-prod.yml）

spring: datasource: type: com.alibaba.druid.pool.DruidDataSource druid: # 连接管理 initial-size: 5 min-idle: 5 max-active: 20 test-on-borrow: true test-while-idle: true time-between-eviction-runs-millis: 300000 validation-query: SELECT 1 # SQL 治理 filters: stat,wall,slf4j connection-properties: druid.wall.db-type=mysql # 监控 stat-view-servlet: enabled: true url-pattern: /druid/* login-username: monitor login-password: ${DRUID_PASS:default_pass} reset-enable: false

第三步：启动验证

• 启动后访问http://localhost:8080/druid/login.html，输入账号密码；
• 查看“数据源”页，确认activeCount初始为 5，poolingCount为 0；
• 执行一个简单查询（如SELECT COUNT(*) FROM product），刷新“SQL 监控”页，确认新 SQL 出现在列表中；
• 故意执行SELECT * FROM product WHERE id = 999999999（返回空），观察executeCount是否增加。

注意：首次启动时，Druid 会预热连接池，activeCount会从 0 缓慢升到initial-size，这是正常现象。如果卡在 0，检查validation-query是否正确，或数据库网络是否通。

4.2 关键环节：WallFilter 白名单配置实战

系统有多个 IP 访问数据库：应用服务器（192.168.10.100）、DBA 临时查询机（192.168.10.200）、备份脚本服务器（192.168.10.250）。WallFilter 白名单必须精确：

druid: wall: white-list: 192.168.10.100,192.168.10.200,192.168.10.250 log-violation: true throw-exception: true

测试方法：

• 用curl -X GET "http://192.168.10.100:8080/api/product?id=1"（合法 IP）→ 正常返回；
• 用curl -X GET "http://192.168.10.200:8080/api/product?id=1 OR 1=1"（合法 IP + 注入）→ 返回 500，日志出现Violation: sql not in allow list；
• 用curl -X GET "http://10.0.0.1:8080/api/product?id=1"（非法 IP）→ 直接拒绝连接，不进应用层。

这个测试验证了双重防护：IP 白名单挡非法来源，SQL 规则挡非法语句。我们曾因此拦截了一次来自 IDC 外网的批量扫库攻击——攻击者 IP 不在白名单，请求直接被 Druid 拒绝，连 Spring MVC 的DispatcherServlet都没走到。

4.3 核心环节：慢 SQL 自动采样与定位

系统有个getOrderDetail接口，平时 200ms，偶发 5s。开启慢 SQL 后：

druid: filter: stat: slow-sql-millis: 1000 log-slow-sql: true

压测时触发慢 SQL，Druid 页面“SQL 监控”中出现：

SQL: SELECT o.*, u.name FROM orders o JOIN user u ON o.user_id = u.id WHERE o.id = ? Execute Count: 12 Avg Time: 4820 ms Max Time: 5210 ms Last Time: 2023-10-15 14:22:33 JDBC Stack: at com.xxx.OrderService.getOrderDetail(OrderService.java:87) at com.xxx.OrderController.detail(OrderController.java:42) Parameters: [100001]

顺着OrderService.java:87查代码，发现此处用了LEFT JOIN但user表没建user_id索引。加索引后，平均耗时降到 180ms。没有 Druid 的慢 SQL 采样，这个问题会一直隐藏在“偶发超时”的模糊描述里，DBA 无法精准定位，开发无法复现。

4.4 核心环节：连接泄漏模拟与自动回收验证

故意写一段泄漏代码：

@GetMapping("/leak") public String leak() { try (Connection conn = dataSource.getConnection()) { PreparedStatement ps = conn.prepareStatement("SELECT 1"); // 忘记 ps.execute() 和 ps.close() Thread.sleep(60000); // 睡 1 分钟 } catch (Exception e) { e.printStackTrace(); } return "ok"; }

调用 3 次后，activeCount升到 8（初始 5 + 3 个泄漏），poolingCount为 0。等待 3 分钟（remove-abandoned-timeout=1800），刷新页面，activeCount降回 5，discardCount增加 3，日志出现：

[Druid-ConnectionPool-Destroy-14024123] discard connection com.alibaba.druid.pool.DruidPooledConnection@abc123 created by connect in 2023-10-15 14:30:22

这证明removeAbandonedOnBorrow生效。再调用/leak，不再新增activeCount，因为泄漏连接已被回收。自动回收不是万能的，但它给了你 3 分钟的故障缓冲期——足够你收到告警、登录服务器、执行jstack定位问题代码。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 问题速查表：高频故障现象与根因定位

5.2 独家避坑技巧：来自三年 12 次线上事故的总结

技巧一：用druid.stat.use-unfair-lock=true解决高并发下的锁争用
Druid 默认用ReentrantLock（公平锁），在 QPS > 3000 时，getConnection()的锁等待时间会飙升。开启不公平锁后，实测maxWait超时率下降 68%。配置方式：

spring: datasource: druid: connection-properties: druid.stat.use-unfair-lock=true

技巧二：log-slow-sql=true时，务必配slow-sql-millis，否则所有 SQL 都记日志
我们曾在线上误配log-slow-sql=true但没设slow-sql-millis，结果日志每秒写入 200MB，磁盘 3 小时爆满。正确姿势是：slow-sql-millis必须显式设置，哪怕设为10000（10 秒）。

技巧三：reset.html不是“清空一切”，它只清监控数据，不重置连接池
curl -X POST "http://localhost:8080/druid/reset.html"后，activeCount不变，poolingCount不变，只是 SQL 统计、慢 SQL 列表被清空。这很好，避免了重置连接池带来的瞬时连接风暴。

技巧四：druid.wall.config-file的 JSON 规则必须 UTF-8 无 BOM
某次部署后 WallFilter 失效，排查半天发现wall-config.json用 Windows 记事本保存，带了 BOM 头，Druid 解析失败静默跳过。用file wall-config.json确认编码，用iconv -f utf-8 -t utf-8 -o wall-config-new.json wall-config.json去 BOM。

技巧五：druid.filter.stat.merge-sql=true时，SELECT * FROM user WHERE id IN (?, ?)和SELECT * FROM user WHERE id IN (?, ?, ?)被视为不同 SQL
因为参数个数不同。若想合并，需在wall-config.json中添加：

{ "rule": [ {