类测验应用多表动态文本生成实现技术咨询

看起来你已经搭建了一个很扎实的基础框架——递归从Texts表拉取并替换密钥的方案，其实是动态内容生成场景里的经典思路，完全没问题！不过跨表查询时的繁琐耦合确实是个常见痛点，我来分享几个能简化流程的优化方向：

1. 用配置表解耦密钥与跨表查询逻辑 #

不要把表名、WHERE条件嵌在密钥里（比如[identifier](table)这种格式），而是给每个跨表查询的密钥起一个语义化的名字（比如[user_top_interest]），然后新增一张KeyMappings配置表来管理查询规则：

• 字段示例：key_name（密钥名）、source_table（来源表）、query_template（带占位符的SQL模板）、param_sources（参数来源，比如标记从用户答案里取user_id）
• 工作流程：扫描到密钥时，先查KeyMappings拿到对应的SQL模板和参数来源，再从用户上下文（比如提交的答案、用户信息）里填充参数，最后执行查询获取内容。

这种方式把查询逻辑和文本内容彻底分开，既避免了密钥格式的复杂性，也方便后续修改查询规则（不用改Texts表的内容，直接更配置表就行）。

2. 替换手动递归，用成熟模板引擎处理 #

自己写递归解析括号密钥的逻辑虽然灵活，但维护成本高，不如直接用现成的模板引擎：

• 比如Python的Jinja2、JavaScript的Handlebars，把Texts表的内容改成模板语法，比如把你适合的方向是[career_match](careers, score>${user_score})改成你适合的方向是{{ get_career_match(user_score) }}
• 然后编写自定义模板函数（比如get_career_match），专门负责从对应表查询数据。模板引擎会自动帮你完成解析、渲染的工作，不用自己写递归扫描逻辑。

3. 预缓存高频跨表数据 #

如果某些跨表数据（比如用户的基础信息、测验的固定配置）在结果生成过程中会多次用到，可以在流程最开始（比如用户提交答案后）一次性查询出来存入内存缓存：

• 比如提前把user_profiles、user_interests的相关数据放到一个user_context对象里
• 后续替换[user_name]、[user_top_interest]这类密钥时，直接从缓存里取，不用反复发起数据库查询，既提升效率也简化逻辑。

4. 分层处理文本片段 #

把文本片段分成两类分别处理：

• 基础静态片段：只依赖Texts表内部的密钥，没有跨表需求，先通过递归替换完成这部分内容的拼接
• 动态数据片段：需要跨表查询的密钥，在静态片段拼接完成后再统一处理

这样拆分后，跨表查询的逻辑会更集中，也能减少不必要的数据库交互次数。

总的来说，你的核心思路（递归替换动态密钥）是完全正确的，问题只是出在跨表查询的耦合方式上。通过上面的方法把查询逻辑和文本内容解耦后，整个流程会简洁很多，后续维护也更方便。

内容的提问来源于stack exchange，提问作者user2868900