swoole中pdo连接复用会放大sql注入风险，因其常驻内存导致prepared statement残留、set sql_mode等会话级配置被跨请求继承，且协程并发共享pdo引发绑定错乱；必须禁用模拟预处理、每次请求独占隔离连接、动态标识符严格白名单校验、禁用连接初始化sql。
为什么Swoole里PDO连接复用会放大SQL注入风险
因为Swoole进程常驻内存，PDO连接一旦被多个请求复用，就可能残留上一个请求的prepared statement或未清理的绑定状态。更危险的是：如果某个请求曾执行过SET sql_mode=''这类初始化语句（常见于Druid/HikariCP配置误搬），后续所有复用该连接的查询都会在宽松模式下执行——导致'1' = 1之类隐式转换绕过参数类型校验，让bindValue($param, '1 OR 1=1', PDO::PARAM_INT)意外变成布尔真。
禁止跨协程共享PDO实例是硬性前提
Swoole协程调度不保证线程安全，同一PDO对象被两个协程并发调用prepare()或execute()，会触发Commands out of sync或MySQL server has gone away，但更隐蔽的问题是参数绑定错乱——比如协程A绑定了id = 123，协程B紧接着执行同一条SQL却没重新绑定，数据库可能沿用旧值或报错。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 必须为每次请求新建PDO实例，或从连接池取隔离连接（不能简单
clone $pdo） - 若用连接池，确保每个连接只被单个协程独占使用后归还，禁止“借出即共享”
- 禁用
PDO::ATTR_EMULATE_PREPARES = true——模拟预处理在复用连接时更容易因字符集缓存不一致导致绑定失效
动态标识符白名单必须在每次请求中重校验
表名、字段名等无法参数化的部分，在Swoole长生命周期中容易被缓存或复用。例如某次请求把$table = $_GET['t']存进静态变量，下次请求直接读取，就跳过了白名单检查。
- 白名单逻辑必须放在请求处理入口，每次调用都走
in_array($table, ['user', 'order'], true)，不依赖任何静态/全局缓存 - 避免在模型boot()或trait中做一次性的表名映射，协程间变量污染会导致白名单失效
- 对ORDER BY、GROUP BY等子句中的字段，同样需独立白名单校验，不能和WHERE条件共用一套逻辑
连接池初始化SQL是高危盲区
很多团队把传统Spring Boot的connection-init-sql照搬到Swoole连接池，比如配了SET NAMES utf8mb4没问题，但若加了SET sql_mode=ALLOW_INVALID_DATES，整个连接生命周期内所有查询都会受其影响，且无法被单个请求覆盖。
- 连接池创建连接时，禁止执行任何
SET类语句，除非明确审计过其副作用 - 字符集必须通过DSN指定：
mysql:host=...;charset=utf8mb4，而非运行时SET - 如需调整sql_mode，应在MySQL服务端统一配置，而不是靠应用层连接初始化
SET SESSION sql_mode=''，它就会一直带着这个宽松模式跑下去——直到连接被销毁。而连接销毁时机又受wait_timeout和应用空闲超时双重控制，中间存在可观测窗口。
