Eloquent属性直接输出可能触发XSS，因accessor未过滤时原始字符串直通浏览器；应在accessor中用htmlspecialchars($value, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8', true)转义，但API场景需避免与$casts冲突，推荐在Resource层统一处理。
为什么直接输出 Eloquent 属性可能触发 XSS
当你在 Blade 模板里写 {{ $user->bio }}，Laravel 默认会 HTML 转义——这没问题；但一旦用了 {!! $user->bio !!} 或通过 __toString()、json_encode()、API 返回等非标准路径输出，原始字符串就直通浏览器。Eloquent 的访问器（accessor）如果返回未过滤的字符串，比如：
public function getBioAttribute($value) { return $value; }，那它和数据库字段本身没区别，完全不防 XSS。
accessor 中手动转义是最可控的方式
在 accessor 里对输出内容做 htmlspecialchars()，能确保该属性「从模型层开始」就带防护。注意必须指定参数，否则默认不处理单引号、不设编码、不关闭 double encoding：
- 用
htmlspecialchars($value, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8', true)—— 第四个参数true关键，防止二次转义 - 不要用
htmlentities()：它会把中文等 UTF-8 字符转成实体，破坏可读性 - 若 accessor 还需支持 JSON 序列化（如 API），得配合
toArray()或$casts处理，否则转义后 JSON 里会出现这类冗余
示例：
protected $casts = ['bio' => 'string']; // 确保是字符串，不是 null 或 object
public function getBioAttribute($value)
{
return $value === null ? '' : htmlspecialchars($value, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8', true);
}
blade 中禁用自动转义时必须走 clean() 流程
遇到富文本场景（如后台编辑器存了 <p>Hello</p>），你确实需要 {!! $user->bio !!}，但绝不能跳过清洗。此时 accessor 不应再做 htmlspecialchars()，而应调用白名单过滤器：
立即学习“PHP免费学习笔记（深入）”；
- 用
strip_tags($value, ['p', 'br', 'strong', 'em'])快速限制标签，但无法防 style/onerror 等属性 - 更稳妥的是引入
league/commonmark（Markdown）或masterminds/html5+HTMLPurifier做完整净化 - 切忌在 accessor 里直接调用
HTMLPurifier::getInstance()->purify($value)：它开销大，且每次访问都执行，影响性能
推荐做法：在控制器或资源类中净化一次，再注入视图变量，而非塞进模型 accessor。
JSON API 输出时 cast 和 accessor 容易互相干扰
Eloquent 的 $casts 和 accessor 同时作用于同一字段时，顺序是：数据库值 → cast → accessor。如果你写了：
protected $casts = ['bio' => 'string'];
public function getBioAttribute($value) { return htmlspecialchars($value); }，那 API 返回的 bio 就是双重转义的 HTML 实体。调试时看到 <script></script> 就是这个原因。
解决办法只有两个：
- API 场景下彻底弃用 accessor 做转义，改用
Resource类统一处理：'bio' => htmlspecialchars($this->resource->bio) - 或者在 accessor 里加运行时判断：
if (app()->runningInConsole() || request()->wantsJson()) { return $value; }—— 但不够健壮，不推荐
真正难缠的不是怎么转义，而是「在哪一层转义」——模型不该承担展示层的编码责任，尤其当同一字段既要 HTML 渲染又要 JSON 输出时，分层失控比没转义更危险。
