参数化绑定和敏感词过滤拦的是两类问题，别当成同一道防线

参数化绑定和敏感词过滤拦的是两类问题：前者对付「外部输入被数据库当成语句执行」，即 SQL 注入这类风险；后者对付「文本内容不适合出现在站点上」，即违规词、营销词与不当表述。判断依据不同，失效后果也不同——参数化绑定失守可能丢数据甚至丢服务器控制权，敏感词过滤失守带来的是内容合规与审核压力。把它们当成同一道防线，通常会出现两种误判：以为开了过滤就加固了注入，或者以为用了 ORM 就不需要审核流程。

两类问题各自的触发点

注入的触发点在查询构造环节：请求参数、表单字段、URL 里的排序与筛选值，如果被直接拼进 SQL 语句，攻击者就能改变语句结构。它关心的是数据如何被解释。

内容风险的触发点在展示与检索环节：留言、商品描述、采集来的正文、用户上传的字段里出现不该出现的词。它关心的是数据说了什么。

参数化绑定做到哪一步

参数化绑定的核心是把「语句结构」和「数据」分开：SQL 模板先定好，用户提供的值只作为参数传入，驱动不会再解析它的语法含义。做到位需要三个条件：所有查询走同一套数据访问层、不允许在业务代码里拼接原始 SQL 片段、对无法参数化的位置（如排序字段名）用白名单校验而不是转义后放行。第三个条件最容易漏，因为它看起来不像注入位。

AnQiCMS 基于 GoLang 开发，技术栈是 GoLang 加 Iris 框架与 GORM，数据访问统一交给 ORM 处理，查询构造不落在模板或业务脚本里；认证侧使用 JWT，配合内置的防 SQL 注入与 XSS 防护，把输入输出的常见风险收敛在框架层。这类能力的价值在于「默认如此」，而不是要求每个二次开发者记得写对。

过滤与审核补的是哪一段

内容侧是另一套流程。AnQiCMS 的内容安全设置包含敏感词过滤、关键词替换与内容审核：过滤按词库拦截，替换把命中的词换成占位或允许的表述，审核决定内容能否进入正式状态。三者分工不同——过滤与替换是自动动作，适合在保存时执行；审核是人工节点，适合在发布前把关。

采集内容与 AI 生成内容都会放大这一段工作量，因为来源不可控。实践里常见的配置是：入库即过滤、命中进审核队列、通过后才允许发布，避免脏内容先上线再补救。

常见误解：把过滤当加固

有两类典型配置看起来安全其实没有闭环。一是「给留言框加了敏感词过滤，就不用管接口参数」——过滤不会改变查询构造，注入面依然在。二是「用了 ORM 就等于输入安全」——ORM 只覆盖走它的查询，绕过 ORM 的手写语句与排序字段仍需要单独校验。

反过来的误解也存在：以为框架层加固了注入，内容就可以免审。框架不判断词义，违规词的识别依赖词库与审核流程。

上线前的两组检查

注入侧三查：确认列表与搜索接口的筛选参数是否走统一数据访问层；确认排序、分页字段是否有白名单；确认错误信息是否会把语句片段暴露给访客。

内容侧三查：确认词库是否覆盖当前业务的禁用表述、并有更新责任人；确认关键词替换规则是否会影响正常内容；确认内容审核状态机是否可追踪，草稿与正式内容分开留痕。

常见问题

只上其一会有什么问题？ 只上参数化绑定，违规内容照样能发布；只上敏感词过滤，注入面完全没被动过，两类风险各自独立存在。

关键词替换能不能替代人工审核？ 不能。替换处理命中词面的表述，审核判断语境与合规边界，命中之外的内容仍需要人来把关。

二次开发时最容易破坏哪一条？ 绕过统一数据访问层手写查询。这一处失效不会报错，只会在被探测时才暴露，代码评审时应把这类写法单独列出。