Marico's space

一致性测试套件只能告诉我们一个库是否通过了自己的测试。它无法回答另一个问题：两个独立实现面对相同的协议流量时，是否会做出相同的决策？ICAO Doc 9303（国际民航组织9303号文件）定义了电子护照应有的行为，但你选择的开源库决定了你的应用程序实际会经历什么。库通过单元测试，整合商通过互操作性测试。但我们停下来太久没问一个更简单的问题：如果两个独立实现接收到完全相同的协议流量，它们会做出相同的

最近踩了几天缓存的坑，发现这玩意儿看起来简单，真要用好，里面的门道比我想的深多了。这篇把第3天的学习整理一下，重点说说缓存失效为什么真的那么难。 回顾 第1天聊了大图（客户端-服务端、扩展性、延迟vs吞吐量），第2天进了数据库（SQL vs NoSQL、复制、分片）。今天的课题本来以为早就懂了：缓存。结果发现我只懂了最容易的那20%。 缓存为什么存在 核心思想很简单：取数据是有代价的（

区块链支付系统标榜透明、快捷、低手续费——但同时也把安全问题的赌注拉到了极致。传统后端出了 bug，大不了服务宕机一会儿。智能合约管着真金白银要是出 bug，资金可能永久打水漂，连撤销键都没有。最近给几个金融科技客户做区块链支付系统，踩了不少坑，这篇把最重要的几条经验捋清楚。 为什么智能合约安全是另一回事 传统 Web 应用的安全逻辑是打补丁：发现漏洞，推送修复，用户更新或服务器重部署。智能合

在Part 3里聊了可观测性，这篇说说自动化这座大山怎么爬。 Azure APIM MCP 现在还是预览版，这意味着什么？你的基础设施即代码（IaC）流水线直接抓瞎： * ARM 模板？不支持 * Bicep？不支持 * Terraform Provider？不支持 * Azure Service Operator（ASO）？也不支持 现实就是这么残酷：标准 IaC 工具一个都用不了

最近折腾 JavaScript 里的 Base64 编码，踩了几个坑，特别是中文字符串直接用 btoa() 直接报错的体验实在太酸爽。这篇把 Base64 的常见坑和实用模式说清楚。 Base64 在 Web 开发里无处不在——JWT 令牌、图片 Data URL、API 载荷、HTTP Basic Auth 头都靠它。但看似简单的 API 其实有不少弯弯绕绕。 BASE64 实际上做了什么

很多人学Docker最大的误区就是还没搞明白底层原理就开始敲命令。比如看到别人跑： docker run nginx 应用起来了，一片祥和，然后就继续往下走了。但你有没有停下来想过：你敲下回车那一瞬间，到底发生了什么？ Docker看起来像是在"魔法般"地运行你的应用，但实际上每次都走同一套流程。想象成这个样子： 你 │ ▼ Docker Client（客户端） │ ▼ Docker En

做后端开发的，估计没少被 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 有 四层独立的缓存，每层都有自己的失效机