mark_safe() 是开发者对 Django 的安全承诺，表示已确认内容不含危险成分；绝不可用于用户输入、未经白名单过滤或含伪事件的 HTML，富文本须先用 bleach.clean() 处理。
mark_safe() 不是 HTML 渲染开关，而是你对 Django 的安全承诺：这段内容我已确认不含 <script></script>、onerror、javascript: 等危险成分。用错就等于主动绕过所有防护。
什么时候绝对不能用 mark_safe()
只要满足以下任一条件，就别碰 mark_safe()：
- 内容来自用户提交（表单、URL 参数、API 请求体、数据库读取的用户字段）
- 内容经过任何中间处理（比如拼接、替换、JSON decode 后再 render）
- 内容没做过白名单过滤（哪怕只留
<p>、<strong>、<ul>，也必须用bleach.clean()显式执行） - 内容里带
style属性、class值含onmouseover=这类伪事件（Django 默认转义不防这个）
富文本内容必须过 bleach.clean() 才能 mark_safe()
比如 TinyMCE 或 CKEditor 返回的 content，直接 {{ content|safe }} 就等于把控制权交给用户。正确流程是：
- 在视图中调用
bleach.clean(content, tags=['p', 'strong', 'ul', 'li'], attributes={}, strip=True) - 再用
mark_safe()包裹结果，传给模板 - 不要在模板里写
{{ content|safe }}—— 过滤必须发生在 Python 层，不是模板层 - 注意
bleach默认不清理style，要显式设attributes={}或用strip=True
误用 |safe 和 {% autoescape off %} 的典型场景
这两个操作实际效果一样：关闭当前上下文的自动转义。常见翻车点：
- 在
{% autoescape off %}块里混入未清洗的变量，比如：{% autoescape off %}{{ user_input }}{{ safe_html }}{% endautoescape %}—— 只要user_input没清洗，整块都危险 - 给昵称、评论、搜索关键词加
|safe，结果用户设昵称为<img src=x onerror=alert(1)> - 用
strip_tags()替代bleach.clean()：它只删标签，不防属性里的 JS，比如<div onclick="alert(1)">会被放过
调试页面暴露的错误信息也是 XSS 入口
当 DEBUG = True 时，Django 500 页面会原样显示数据库错误详情（如 Key (username)=(<script>...</script>) already exists）。这类内容根本没走模板变量流程，|safe 和 mark_safe() 都不适用，但风险真实存在：
立即学习“Python免费学习笔记（深入）”；
- 生产环境必须设
DEBUG = False，这是硬性要求 - 即使开发环境，也要避免让非开发者访问调试页（比如用
ALLOWED_HOSTS限制、反向代理拦截） - 升级到
Django >= 1.11.5或2.0+，老版本（如 1.11.4）在错误页渲染时有force_escape逻辑缺陷，会漏转义
mark_safe() 的责任不在框架，在你。它不校验内容，只取消校验。真正难的不是写那行代码，而是确认“这段 HTML 我真敢签生死状”。 
