不把 API Key 写进前端代码：一个 BFF 层的鉴权实践
大模型应用开发中，前端直接调用 API 极易泄露 Key。标准解决方案是 BFF 模式：前端只调自己的后端，由后端持有 Key 并转发请求。文章给出了 Node.js 完整实现，涵盖身份校验、请求转发、流式输出处理，并强调多层安全加固，如 IP 白名单、用量控制和 Key 轮换，确保 API Key 永不暴露于客户端。
接手屎山代码时，我让 AI 把接口逻辑和业务语义自动填进了文档
接手无文档老项目时，用AI按接口分析调用链并自动生成业务语义文档，效率极高。核心流程分四步：先让AI扫描项目结构建立全局认知；再逐接口追踪完整调用链，区分代码含义与业务含义；接着通过多轮对话补全业务场景和规则；最后格式化输出可直接交付的接口文档。该方法比人工编写更可靠、高效，37个接口仅需40分钟，但依赖清晰的代码结构和主流框架。
切库不停机：一套分库分表灰度方案的设计与踩坑记录
订单系统需在线完成分库分表，方案核心是在新旧库间加入动态路由层，通过配置中心实现按用户ID取模的灰度切流。整体架构分为路由决策、配置管理与数据同步三层，并重点解决了全量同步冲突、切流瞬间双写、同步延迟导致数据不可见以及分片键变更等关键问题。最终历时22天完成切换，实现了零停机与性能大幅提升。
手动埋点还是全扔给自动化？我按三个维度梳理了自定义性能打点的时机与粒度
手动打点和自动化采集并非替代关系，而是分工关系。文章从采集成本、数据精度和长期维护三个维度划定了分界线：触发条件复杂、需要业务语义判定、与业务代码共生的指标应手动打点；纯技术指标如页面加载、HTTP请求等则交给自动化工具。建议用PerformanceObserver统一收拢上报，实现低成本、高精度的性能监控。
前端调用大模型 API，我在请求层用这三层缓存把成本打下来了
前端调用大模型API时，通过三层缓存策略有效避免重复请求造成的费用浪费。内存缓存（LRU算法）解决组件重渲染和短时重复调用；sessionStorage持久化缓存支持跨页面恢复，避免刷新后重复请求；请求去重队列确保并发相同请求只发一次网络调用。三层协作可将命中率提升至80%左右，显著降低成本。
团队协作时接口文档老打架，试试这样合并和消解冲突
从单体 OpenAPI 文件迁移到多文件结构，是解决接口文档冲突的根本方法。通过按模块拆分规范文件，并利用构建命令拼装完整文档，可将冲突率降低 90% 以上。核心操作包括：将路径、模式等定义拆分为独立文件，用 `$ref` 在入口文件中组装，并借助 Redocly CLI 进行构建与校验。对于同一模块的并发修改，可进一步按 HTTP 方法拆分文件。若冲突发生，使用 Git 的 `union` 合并策略和编辑器插件能高效解决。
分库分表后，分布式事务怎么选：本地消息表真的过时了吗，Seata 又踩了哪些坑
分布式事务在分库分表后挑战巨大。本地消息表在分库不分服务时依然可控，但分库又分服务后，其延迟与扫表热点问题凸显。Seata AT模式虽代码侵入性低，但运维复杂，存在TC高可用、undo_log膨胀、读未提交隔离导致脏写等深坑。选型需看场景：低QPS、无并发冲突可用AT；高并发或强一致性场景推荐TCC或Saga；异步解耦则用事务消息加本地幂等表最稳。
采样率从 100% 降到 1% 之后，我们靠这 4 种策略保住了排查精度
采样率降至 1% 而精度不降，依赖动态采样、分层保留、上下文补全和查询时重建四种工程策略。动态采样按请求重要性分配采样预算，确保异常全留；分层保留将数据按粒度分热、温、冷三层存储，大幅降低成本；上下文补全通过 TraceID 透传从日志中找回缺失 Span；查询时重建利用冷层全量摘要快速定位问题。
把 prompt 版本写进前端代码库：大模型输出质量不再随部署漂移
将 prompt 视为前端代码的一部分进行管理，通过 Git 实现版本控制，从根本上解决了因随意修改导致的模型输出质量漂移问题。核心方案是将 prompt 定义为 TypeScript 常量，通过 prompt_id 和版本号实现前后端同步，并采用不可变版本升级策略。这确保了 prompt 变更可追溯、可回滚、可审查，并可通过构建时校验防止外部篡改。
用 TypeScript 类型做接口文档，怎么让它跟后端返回保持同步
解决前后端接口类型不一致的核心方案：将 TypeScript 类型定义作为唯一真相来源，通过工具链实现自动化校验。具体做法是用 ts-json-schema-generator 将类型编译为 JSON Schema，再在 CI 中用 Ajv 校验实际响应数据。也可从后端代码直接生成前端类型，或用 OpenAPI 作为中间契约，配合 openapi-diff 检测破坏性变更。针对泛型、联合类型等复杂场景需注意工具版本和配置优化。