在 Jinja2 中渲染含双引号的字符串（如 Go 代码）时，默认 HTML 转义会将 " 变为 "；解决方法是使用 |safe 过滤器禁用自动转义，或改用反引号（`）绕过问题。
在 jinja2 中渲染含双引号的字符串（如 go 代码）时，默认 html 转义会将 `"` 变为 `"`；解决方法是使用 `|safe` 过滤器禁用自动转义，或改用反引号（`` ` ``）绕过问题。
Jinja2 默认对变量输出执行 HTML 转义（escaping），这是出于安全考虑——防止 XSS 等注入风险。但当你用 Jinja2 生成非 HTML 内容（如 Go 源码、Shell 脚本、JSON 配置等）时，这种转义反而会破坏语法。例如：
# Python 渲染逻辑
list_s = ['a', 'b']
string = '"' + '", "'.join(list_s) + '"'
final_string = f'Function({string})' # → 'Function("a", "b")'
template.render({'function': final_string})
对应模板：
e.({{ function }})
结果却输出了 e.(Function("a", "b")) —— 因为 {{ function }} 自动将双引号转义为 HTML 实体。
✅ 推荐解决方案：使用 |safe 过滤器
只需在模板中显式声明该变量内容是“可信且无需转义”的：
e.({{ function|safe }})
此时 Jinja2 将原样输出 Function("a", "b")，最终得到符合 Go 语法的：
e.(Function("a", "b"))
⚠️ 注意事项：
-
|safe仅应在完全可控、无用户输入参与的上下文中使用。若function字符串来源于不可信输入（如表单、API 请求），直接|safe可能引入代码注入风险； - 若需兼顾安全性与语法正确性，可结合预处理：在 Python 端用
json.dumps()生成合法 JSON 字符串，再在模板中用|safe渲染（适用于嵌入 JSON 的场景）； - 替代方案（如改用反引号
`a`, `b`）虽可行，但属于“规避”而非“解决”，且受限于目标语言是否支持（Go 支持反引号字符串，但其他语言如 Python 不支持多行字面量以外的反引号语义）。
? 总结：
Jinja2 的 |safe 是专为非 HTML 输出设计的标准机制。它比手动拼接转义字符（如 \"、"）更可靠、更简洁，也避免了因转义层级混乱导致的调试困难。只要确保数据来源可信，{{ variable|safe }} 就是最直接、最符合 Jinja2 设计哲学的解法。
