题干与适用场景
团队升级到 Python 3.14，希望让模板处理器在拼接字符串前检查插值值。请解释 t-string 产生什么对象、如何遍历片段，以及如何避免把模板 API 误当成自动转义。
PEP 750 为 Python 3.14 引入模板字符串。t"..." 不会直接产生 str，而是产生 string.templatelib.Template，其中保留静态字符串片段和插值对象，应用可以在最终拼接前执行校验、转义或领域转换。
面试官考察点
重点包括：区分 f-string 的立即字符串化与 t-string 的结构化结果、理解 Template 和 Interpolation 的字段、处理原始值与格式说明、设计上下文相关转义、控制副作用和兼容旧 Python 版本。
30 秒回答框架
“我会先强调 t-string 不是自动安全输出。它把模板解析成静态片段和插值对象，渲染器可以检查原始值、表达式文本、转换和格式说明，再按 SQL、HTML 或日志上下文执行专用编码。模板本身不应执行任意字符串拼接；我会限制允许的值类型，测试嵌套模板、格式说明、异常和旧版本回退，并把最终输出当作不可信数据继续验证。”
分步骤深入解答
第一步：区分 f-string 与 t-string
f-string 会先求值并格式化成 str，中间结构不可恢复。t-string 使用 t 前缀，结果是 Template；静态文本与插值仍分开，渲染器可在合并前检查每一项。
第二步：理解核心对象
模板由字符串片段和 Interpolation 组成。插值记录值、表达式文本、转换标记和格式说明，便于策略根据来源或目标上下文做决定。不要假设遍历结果就是已经安全的最终字符串。
第三步：写出最小处理器
下面的处理器仅演示结构化遍历，真实系统仍需按上下文编码：
from string.templatelib import Template
def render_plain(template: Template) -> str:
parts = []
for item in template:
if isinstance(item, str):
parts.append(item)
else:
parts.append(str(item.value))
return "".join(parts)
message = t"Hello, {name}!"str(item.value) 只适合无安全要求的纯文本示例；SQL、HTML、Shell 和日志必须使用各自的参数化或编码 API。
第四步：处理转换与格式说明
插值可能带有 !s、!r 或格式说明。渲染器应先决定是否允许转换，再对转换后的值应用目标上下文编码。不能把 repr 当作 HTML 转义，也不能让格式说明绕过类型白名单。
第五步：避免副作用表达式
t-string 仍会求值插值表达式来建立 Interpolation。模板处理器不能把 t-string 当成沙箱；若模板来源不可信，风险在模板构造阶段已经存在。对插件或用户输入只接受数据占位符，禁止动态执行表达式。
第六步：按输出上下文选择策略
纯文本可以按允许类型转换；HTML 应使用经过审计的 HTML 转义器；SQL 应使用驱动参数绑定；Shell 应避免拼接并使用参数数组；结构化日志应传递字段而不是拼成一行。Template 提供结构，不替代这些安全边界。
第七步：兼容版本与 API 发现
Python 3.14 提供 string.templatelib。支持旧版本时应通过版本适配选择已有模板库或明确降级为 f-string，不要假装能在旧解释器上保留插值结构。启动时检查运行时版本，CI 覆盖每个支持版本。
第八步：测试和观测
测试静态片段、嵌套 t-string、格式说明、异常、对象 __format__ 副作用和大模板。记录策略拒绝的值类型与模板来源，但不要把插值内容写进可能公开的日志；对输出做上下文专属的安全回归。
设计取舍与边界
结构化处理还是简单拼接
需要审计、国际化或多种输出目标时，保留结构能让策略前移；一次性纯文本脚本用 f-string 更简单。团队应按风险和复用范围选择，不为所有字符串都引入模板管线。
灵活格式还是可预测类型
允许任意 __format__ 会提高表现力，也会引入副作用和类型漂移。公共渲染器应限制值类型、转换和格式说明，并对拒绝给出可诊断错误。
模板对象还是最终字符串
Template 适合在边界内传递，最终输出仍应在发送、存储或执行前再次按上下文检查。不要把 Template 当作已经完成编码的安全令牌。
失败演练与演进计划
HTML 转义被绕过
让插值实现自定义 __str__ 返回带标签内容，确认纯 str 转换不会自动安全；改用上下文编码并加入恶意值回归。
格式说明触发异常
使用不支持的格式说明和对象 __format__ 抛错，验证处理器能定位具体插值并拒绝整次渲染，而不是返回半截输出。
旧解释器误运行
在 Python 3.13 启动同一模块，确认版本检查给出清晰错误或走显式兼容实现，不能把语法错误留到生产。
常见误区与追问
误区一：认为 t-string 自动转义
追问：它解决了什么？它保留了结构，方便应用在拼接前做策略处理；SQL、HTML 等安全仍由专用 API 负责。
误区二：认为插值表达式不会执行
追问：什么时候求值？构造 t-string 时表达式会求值并记录结果，因此不可信模板不能通过 t-string 获得沙箱能力。
误区三：把 repr 当作安全编码
追问：为什么不行？repr 是调试表示，不保证符合 HTML、SQL、Shell 或日志字段的编码规则。
延伸追问与参考答案
t-string 适合替代所有 f-string 吗？
不适合。只有需要在合并前检查或转换插值的边界才有结构收益；普通纯文本仍可使用 f-string。
如何为 SQL 设计渲染器？
不要生成 SQL 字符串；把静态片段与值映射到驱动的参数占位符，值通过参数绑定传递，模板只承担语法结构描述。
如何处理旧 Python 版本？
启动时检查版本，在 3.14 使用 string.templatelib，旧版本使用已有模板实现或明确不支持，并用同一组安全语义测试验证差异。