SQLite跨生产与归档库查询如何适配列名差异，减少重复开发

该需求完全可行，且不需要编写两套独立的复杂查询，仅需极少量的适配逻辑即可完成兼容，同时需要注意规避SQLite静态解析的特有坑点。

推荐实现方案 #

方案1：程序层元探测+字段名替换（改造成本最低） #

• SQLite内置pragma_table_info元数据接口，仅需执行一条极短的探测语句，即可快速判断当前连接的库是否存在生产库专属的message列，耗时仅几毫秒。
• 探测语句示例：
  SELECT COUNT(*) FROM pragma_table_info('你的业务表名') WHERE name = 'message'
• 如果是在代码里拼接SQL，仅需加一行三元判断即可完成替换：探测返回1就用message，返回0就用message_id，原有长查询的其余JOIN、WHERE、排序、聚合等复杂逻辑完全不需要改动，无需维护两套查询代码。
• 兼容所有SQLite版本，不存在解析报错风险。

方案2：会话级临时视图兼容（适合不方便修改查询拼接逻辑的场景） #

• 该方案仅需在执行原有长查询前，增加2行预处理逻辑，即可实现字段统一适配，原有查询几乎不需要改动。
• 预处理流程：
  1. 先执行元探测语句判断当前库类型：SELECT EXISTS (SELECT 1 FROM pragma_table_info('你的业务表名') WHERE name = 'message') AS is_prod
  2. 如果is_prod返回1（生产库），创建会话级临时视图：
     CREATE TEMP VIEW unified_table AS SELECT *, message AS unified_msg FROM 你的业务表名
  3. 如果is_prod返回0（归档库），创建会话级临时视图：
     CREATE TEMP VIEW unified_table AS SELECT *, message_id AS unified_msg FROM 你的业务表名
  4. 原有长查询直接将原业务表替换为unified_table，将原查询中引用message/message_id的位置改为unified_msg即可，其余逻辑完全复用。
• 临时视图仅在当前数据库会话生效，连接断开后自动销毁，不会修改原库的表结构。

避坑提示 #

• 不要直接在单条查询内写类似CASE WHEN EXISTS (...) THEN message ELSE message_id END的条件分支逻辑：SQLite是静态解析器，会先扫描全句的所有列名确认存在性，再执行逻辑分支，只要SQL语句文本中出现了当前库不存在的列名，哪怕该列名对应的分支永远不会被执行，都会直接抛出no such column的错误，这也是这类适配最常见的踩坑点。

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