<p>Webman中防SQL注入须严格使用参数化查询：禁用字符串拼接，原生SQL用PDO占位符（?或:id）配合execute()传参；ThinkPHP Db类调用Db::query("SELECT * FROM user WHERE name = ?", [$name])安全；ORDER BY等无法参数化处须白名单校验；数据库账号遵循最小权限原则。</p>
Webman 本身不内置 SQL 注入防护逻辑，所有数据库操作的安全性完全取决于你如何写模型层和查询代码。用错方式拼接 SQL，哪怕用 Webman 框架也照被拖库。
webman 中直接执行原生 SQL 时怎么防注入
Webman 默认使用 ThinkPHP 的 Db 类或 Laravel 的 Eloquent（取决于项目结构），但很多团队会绕过 ORM 直接调用 PDO 或 mysqli 执行原生 SQL。这时最容易踩坑。
- 绝对禁止用字符串拼接构造
WHERE条件，比如"SELECT * FROM user WHERE id = " . $id - 必须用 PDO 的命名参数（
:id）或问号占位符（?），并配合execute()或query()的参数数组传入值 - 如果用的是 ThinkPHP 的
Db::query()，它支持参数化：Db::query("SELECT * FROM user WHERE name = ?", [$name]) - 注意：
Db::table('user')->where('name', $name)->select()这类链式调用是安全的，底层已做参数绑定
app/model/ 下的 Model 类是否自动防注入
不是自动的——取决于你用的是哪种写法。Webman 常见搭配是 ThinkPHP 的 Model 或自定义 PDO 封装，两者行为不同。
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- ThinkPHP Model（如继承
\think\Model）：所有where()、find()、save()方法默认走预编译，$model->where('email', $_GET['email'])->find()是安全的 - 手写 PDO 模型（如
new PDO(...)后自己拼 SQL）：完全不防注入，哪怕在app/model/Test.php里也一样危险 - 特别注意
whereRaw()、whereExists()等“原始条件”方法：它们接受原生 SQL 字符串，必须手动转义或改用参数占位符
哪些地方容易漏掉导致注入风险
最常被忽略的不是主查询，而是辅助逻辑里的动态片段。
-
ORDER BY字段名不能参数化，所以不能直接用用户输入：ORDER BY $_GET['sort']是高危写法；应限定白名单，比如in_array($sort, ['id', 'name', 'created_at']) ? $sort : 'id' -
LIMIT的偏移量和数量虽是整数，但仍需(int)强转或intval()，避免LIMIT 0,1 UNION SELECT ...类攻击变体 - 日志记录、调试输出中若拼接了用户数据进 SQL 字符串（哪怕只写到文件），也可能被用于二次利用
- 使用
Db::raw()构造子查询时，如果内部嵌套了未过滤的变量，整个链路就失效
除了代码层，Webman 部署时还能做什么
代码防住 95%，剩下 5% 得靠运行时兜底。Webman 是常驻进程，这点比传统 PHP-FPM 更需警惕。
- 数据库账号必须遵循最小权限原则：Webman 应用账号只授予
SELECT, INSERT, UPDATE, DELETE，禁用DROP、CREATE、LOAD_FILE等高危权限 - Webman 自身不带 WAF，但可以前置 Nginx，用
ngx_http_geoip2_module或第三方模块拦截含' OR '1'='1、UNION SELECT的请求 - 开启
display_errors = Off和log_errors = On，防止数据库报错暴露表名、字段名等敏感结构 - 别忽略
php.ini中的magic_quotes_gpc（已废弃）或mysql.trace_mode（无意义），这些伪防护反而干扰真实防御逻辑
真正难防的从来不是典型 ' OR 1=1，而是那些藏在排序、分页、导出 CSV、模糊搜索关键词里的非常规拼接点。只要有一个地方松动，参数化就形同虚设。
