CI4 中彻底移除 xss_clean，必须显式调用 esc() 按上下文编码输出；CI3 的 xss_clean 仅能防低风险手误，无法防御现代 XSS 攻击。
CI4 里根本不用配 xss_clean，它已被彻底移除；CI3 里配了也防不住现代 XSS，靠它等于没防。
CI4 中必须用 esc() 而不是幻想“自动过滤”
CI4 没有 xss_clean() 函数，也不支持 $config['global_xss_filtering'] = TRUE。所谓“全局过滤”在 CI4 中不存在，强行改配置无效。
- 所有动态输出都得显式调用
esc()，比如= esc($user_input, 'html') ?>、= esc($js_data, 'js') ?> - 输出到 HTML 属性时用
'attr'，URL 地址用'url'，CSS 内联样式用'css'—— 错用类型（比如把 JS 字符串用'html'）会直接失效 -
esc()不处理富文本；若需保留<p>、<strong>等标签，必须配合 HTML Purifier 白名单过滤，不能只靠esc() - 控制器里别对输入做“清洗”再存库 —— 输入应原样存储，输出时才按上下文编码；否则可能破坏密码、代码片段等合法特殊字符
CI3 的 xss_clean() 只能当“防手滑”用，不能信它能防攻击
CI3 的 xss_clean() 是基于正则的字符串替换，不解析 DOM，对大小写混淆（OnErRoR）、空格分隔（on error=）、注释干扰（on<!-- -->error=）、SVG 标签（<svg onload="alert(1)">）基本无效。
- 仅适合极低风险场景：后台录入的纯文本字段（如“备注”“状态名”），且不渲染为 HTML
- 表单验证中加
|xss_clean规则，不如直接删掉 —— 它不解决根本问题，还掩盖真实漏洞 - 启用
$config['global_xss_filtering'] = TRUE会导致所有 POST/COOKIE 数据被 strip_tags() + 正则清理，可能毁掉富文本、JSON 字符串、甚至带符号的密码 - 文件上传校验必须用
$this->security->xss_clean($file, TRUE)，这是唯一被 CI3 官方认可的可靠用途
CSRF 配置不等于 XSS 防护，别混在一起
CSRF 和 XSS 是两类完全不同的攻击，配置 csrf_protection 对 XSS 零作用。但很多人误以为开了 CSRF 就“安全了”，结果在模板里直接输出 = $comment ?>。
- CI4：必须在每个表单里写
= csrf_field() ?>，AJAX 请求要从 Cookie 读csrf_cookie_name并设请求头X-CSRF-TOKEN - CI3：用
form_open()自动生成隐藏字段，或手动拼<input name="= $this->security->get_csrf_token_name() ?>" value="= $this->security->get_csrf_hash() ?>"> - CI4 的
$csrfRegenerate = true默认每次提交换令牌，对多标签页、浏览器后退不友好；若业务允许，可设为false但需接受略低的安全强度
真正麻烦的从来不是配哪个开关，而是每处 = 后面有没有跟 esc()，以及你是否清楚当前变量要插进 HTML、JS 还是 URL —— 这些细节漏一处，前面所有配置都白搭。
