remove_invisible_characters 不可用于 XSS 或 SQL 注入防护，它仅清理部分 ASCII 控制字符和宽松判定的无效 UTF-8 序列，不处理 Unicode 格式字符、零宽空格，不转义 HTML、不校验协议，且默认不解析 URL 编码。
这个函数不安全，别在敏感场景用它做 XSS 或 SQL 注入防护。
remove_invisible_characters 会删掉哪些字符
它主要清理 ASCII 控制字符（\x00–\x08、\x0B、\x0C、\x0E–\x1F、\x7F），以及 UTF-8 中的“无效多字节序列”——但判断逻辑很宽松，比如把 \xE0\x80\x80 这类看似非法、实则可能被某些解析器接受的序列也放过了。
- 它不处理 Unicode 格式字符（如
\u202ERTL 覆盖）、零宽空格（\u200B）等现代 XSS 常用绕过手段 - 对 UTF-8 的“修复”只是简单截断或替换为
?，不是标准化重编码 - 原始实现里还硬编码过滤了
%00–%08、%0B、%0C、%0E–%20这些 URL 编码片段，但只在$url_encoded为 true 时触发，而默认是 false
为什么不能靠它防 XSS
它设计目标是“让输入更干净”，不是“让输入可信任”。比如输入 <script>alert(1)</script> 完全不会被它动一下；再比如 javascript:alert(1) 里的冒号和括号全是可见字符，照常通过。
- 它不做 HTML 实体转义，不剥离标签，不校验协议白名单
- 在表单提交、JSON 解析、SQL 拼接前直接调用它，等于什么防护都没加
- CodeIgniter 3.x 中该函数被
xss_clean()内部调用，但后者本身也已被官方弃用（CI 4 彻底移除）
替代方案怎么选
根据你真正要解决的问题来定，不是找一个“看起来像过滤”的函数顶包。
- 存数据库前：用预处理语句（
$this->db->query()配绑定参数），别拼 SQL 字符串 - 输出到 HTML：用
html_escape()（CI 3）或原生htmlspecialchars($str, ENT_QUOTES, 'UTF-8') - 需要更严格净化：引入
HTMLPurifier，配置好白名单规则，而不是依赖内置函数 - 验证手机号/邮箱等：用
filter_var()+ 对应FILTER_VALIDATE_EMAIL等，比清洗更可靠
如果必须用，至少注意这三点
有些老项目一时改不动，得继续用它，那就得知道边界在哪。
- 永远把它放在过滤链最前面，而不是唯一一步——比如先
remove_invisible_characters()，再trim()，最后html_escape() - 别传
true给第二个参数（$url_encoded），它会对%3Cscript%3E这类做解码再清洗，反而可能触发二次解析漏洞 - CI 3.1.11+ 版本修复了部分 UTF-8 截断 bug，但没改核心逻辑，升级不能当安全补丁用
真正麻烦的从来不是函数调不调用，而是调用位置、上下文、后续是否还有其他处理。一个字符清洗函数，救不了没分层的输入输出逻辑。
