Marico's space

做后端开发的，估计没少被 API 的坑折腾过。字段少了一个、状态码返回错了、高并发下超时了、接口契约改了导致调用方全挂了——这些问题用临时手动测的方式，靠运气能碰上几个，但系统化地测才能真正把它们抓出来。 一套好的 API 测试策略，说白了就是回答三个问题：测什么、谁来测、什么时候跑。把快速检查和慢速套件分开，提交代码时跑轻量级检查，定时或发布前跑完整回归，既能保证覆盖率，又不让每个开发流程都卡

最近折腾了一下 CI/CD 测试管理，把 GitHub Actions、GitLab CI 和 Jenkins 三套流水线都跑了一遍，顺手做个横向对比。这三个工具的选型文章一搜一大把，但大多是在对比功能列表，配置文件的写法却很少有人放到一起对照着看。这篇不一样——我用同一套测试用例（Jest + Supertest，8 个接口测试，100% 覆盖率），分别写三份配置文件跑一遍，然后把真实配置贴出来

最近折腾了用大语言模型（LLM）来自动生成和维护 API 测试，踩了不少坑，这篇把实操经验说清楚。 需求不是"帮我生成测试数据"这种简单活儿——我想让 AI 真正理解我的 API 接口，自动写测试用例，并且当接口变更时能同步更新测试代码。 下面是我的完整踩坑记录，代码都是实际跑通过的。 我想解决什么问题 维护的 API 主要处理用户管理、计费和 webhook 回调，大约 40 个接口。

最近折腾 Next.js App Router 的缓存机制，踩了几个坑才搞清楚这玩意儿到底是怎么工作的。部署上去之后调了 revalidatePath()，页面还是显示旧数据；或者关了某个 fetch 的缓存，结果页面居然还被缓存了；再或者从 Next.js 14 升级到 15 之后，原本好好的缓存策略全崩了。 这些问题的根源都一样：App Router 有 四层独立的缓存，每层都有自己的失效机

最近折腾 ClickHouse® 部署，在安全这块踩了几个坑。默认安装跑起来是快，但说实话，生产环境直接用就跟裸奔差不多。查了一圈资料，把安全加固的路子摸清楚了，这篇把核心要点说清楚。 为什么数据库安全不能忽视 ClickHouse® 跑着 BI 看板、监控系统、财务报表、IoT 数据分析这些业务，里头全是敏感信息——客户数据、财务记录、运营指标、商业机密。安全没做好，数据泄露、恶意访问、服

半年前，半夜两点我在线上修bug。我们的API响应时间已经飙到3.2秒，用户在群里炸锅，数据库CPU打满快要冒烟了。组里一个刚入职的小兄弟出的主意是："要不加台配置更高的服务器？" 那天晚上我悟出一个道理：给一辆轮胎没气的车换大排量发动机，能跑快才怪。真正的问题几乎永远是缓存——但不是你从StackOverflow搜到的第一种解法那种缓存。 下面是真正有效的方案，按效果排序。 1. API

打开 CI 日志，想搞清楚为什么一个 PR 跑了 9 分钟才变绿。本地测试明明只需要 40 秒。翻到上面一看，罪魁祸首：覆盖率任务。同样的测试用例，只是套了个 Xdebug，每个断言都像爬一样。 大多数团队从来不把这两个数字拆开看。看到"测试耗时 9 分钟"，就以为是测试本身慢。其实不是。慢的是覆盖率驱动。而且修复方法只是 CI 配置里改一行代码，但几乎没人做过，因为根本没想过要去测一下时间到底

很多团队的开发工作止步于"能跑就行"。Jira tickets 关闭了，功能上线了，就万事大吉。但对于真正的工程师来说，这只是起点——真正的挑战在于代码不再只是文本，而是开始与基础设施产生真实的交互那一刻。 我决定开一个 ENGINEERING 专栏，因为我坚信：性能不是上线前临时抱佛脚的"调优"，也不是在死线前慌慌张张加个缓存。性能是架构的根基。 为什么要聊这个？ * 开发经济学：一个

最近折腾了自己的作品集（Portfolio）网站，踩了几个坑，总结出一套实用的优化思路。加载速度、SEO排名、日常维护，这三个问题搞定了，网站才能真正为你服务，而不是成为需要你伺候的累赘。下面直接说干货。 1. 先选个轻量级技术栈 性能优化的最大收益，其实在你写第一行代码之前就决定了。 * 技术栈要精简。静态站点生成器（Astro、Next.js 静态导出、Hugo，甚至纯 HTML/C

最近折腾 AI Agent 的长期记忆系统，踩了几个坑，这篇把问题说清楚。 一开始大家都觉得长期记忆必须得上向量数据库，得搭 RAG 管道。但看了一圈真正扛住大流量的 Agent 产品，发现它们不约而同选了更简单的方案：纯文本文件。 这不是技术退步，反而是个更强的工程选择。文件可追溯、可对比、可迁移，还能直接 Git 版本管理。 不过光有一堆文本还不够，想让这种方案真正 work，必须把存储