经过几个月的渐进式重构优化，V2 版接口顺利上线，接口响应时间大幅降低、也比第一版本的接口耗时更稳定。

记录一下项目之初做错了什么？

• 使用 PostgreSQL JSONB 数据类型存储过重的元数据，后续业务的扩展导致数据量过大，批量获取会面临查询、解析等一系列性能问题；
• API 接口返回内容过多，且随着业务发展字段越加越多，单资源数据 100 KB+，批量获取传输耗时显著增长；
• Go 并发是甜甜的陷阱，第一版接口在遇到性能问题后使用 Go 协程 + 二级缓存（Redis + 内存缓存）的策略进行优化，且通过接口自动构建缓存，接口的耗时产生抖动，忽高忽低；
• 短期内确实解决了性能问题，治标不治本，也因着二级缓存方案被作为解决性能问题的基础策略，在多个模块中使用，陆续的缓存不一致问题开始出现，定位问题变的困难。

此时接口已积重难返，无法继续优化：前有接口返回结构无法更改、后有缓存不确定性虎视眈眈。

吸取了经验教训，V2 版的接口做了以下调整：

• API 默认返回基础结构，需要各样附加信息使用参数声明作为附加数据返回；
• 通过 Task 预先构建宽表数据源，JSON 数据拍平，非元数据内容移到业务表、资源表，接口从数据库直接走仅索引查询；

效果良好，获取基础数据时耗时大幅降低，且没有耗时抖动问题，额外的好处是可测试性大幅提升，数据库中的数据所见即所得。