Marico's space

最近折腾 MySQL 8.4，在几套生产环境里踩了几个坑，这篇把问题说清楚，不整虚的。 MySQL 依然是国内最流行的数据库之一，从电商、ERP到各种后台系统，到处都在跑。但说实话，我见过太多服务器配置拉满却还是慢得像蜗牛的情况——问题往往不在硬件，在于那些没人管的配置和SQL。 MySQL 8.4 LTS 确实带来了不少改进：优化器更聪明了、统计信息管理更完善、对JSON的支持也顺手多了。但

先交代一下背景：做 TerraTier（一个 3 层 AWS 架构项目）的时候，我一直在想能不能换个方向折腾点不一样的东西。TerraTier 解决的是基础设施层的问题——网络、安全边界、密钥管理。那这个项目想解决的，是运维层的问题：Terraform 代码跑完之后，如果有人在 AWS 控制台手动改了一通，会发生什么？ 于是就有了 TerraGuard AI——一个事件驱动的漂移检测系统，核心思

最近折腾大规模 Web Scraping、动态价格监控和给大模型喂数据的管道，遇到最头疼的问题就是：代理流量费用这笔账到底怎么算。 每个主流供应商都会给你画同样的饼："99.9% 可用率保证、数百万住宅节点、超低延迟。" 但上了生产才发现，这些宣传数字根本不等于真实效果。上个月我们团队决定不猜了，自己搭了一套自动化测试沙箱，对几个企业级节点做了持续压力测试。 分析了几百万次请求之后，发现的情

你的 AI 编程 agent 写出来的东西看起来没问题。脑子里过一遍，编译通过了。然后你发现它调用了 user.getProfileById() —— 一个代码库里根本不存在的方法。 你从来没让它编造这个方法。它非常自信地在代码里塞了一个，中间部分反而写得挺正常。这就是最恶心的错误：不是明显崩溃，而是悄悄地、有偏差地不正确，你得自己抓出来。 如果你在真实项目里用过 Claude Code、Cu

最近帮人做技术尽调，遇到一个挺有意思的现象：很多公司的技术团队其实不清楚自己的系统到底"健康"到什么程度。你问他代码质量怎么样，他说"还行吧"；问他数据库设计合理吗，他说"能跑"；问他系统能扛住双十一吗，他说"应该可以吧"。 这种模糊的判断对企业决策来说是很危险的。我做技术审计这些年，逐渐摸索出一套12维度的评估框架，每个维度打分0-10，有对应的风险等级，最后汇总成一份有优先级的行动清单。这套

最近折腾了一下 RAG（检索增强生成）系统，把 Claude 和 ChatGPT 的 API 串起来用，踩了几个坑，这篇把关键点说清楚。 我们这套系统会把文档检索和两个大模型的能力结合起来：用户提问 → 从文档库拉相关资料 → 把上下文喂给 AI → 生成答案。这种玩法在客服机器人、技术文档问答这类场景很实用。 准备工作 * Node.js v18.0 或更高版本 * OpenAI A

最近折腾 Supabase Auth 的 E2E 测试，踩了一个很经典的坑：邮件验证。 Supabase 的注册流程会发送一封验证邮件，测试需要点击邮件里的链接或填写 OTP（一次性密码）。但问题是——邮件发出去了，你的测试脚本根本够不着它。 官方的建议是用 InBucket——Supabase 本地开发的邮件拦截工具。但这玩意儿依赖 Docker，得在 CI 流水线里跑一个完整的 Supab

最近折腾了自家 Go PDF 库的性能优化，踩了不少坑，这篇把踩到的反模式和盘一托出来。 我们跑了一套自研的静态分析检查工具（内部代号 SlopGuard），对着 Go PDF 库扫了一遍。结果出来了 226 个问题，其中 218 个是真实的性能隐患——全修完了。 下面说说都发现了什么、改了什么代码、以及最终 PDF 生成速度快了多少。 背景 GoPDFSuit 是一款面向高并发 PDF

最近折腾了一个电商比价插件 Arbitra，把日本几个主流购物网站的价格抓下来比一比。说实话，日淘的价差比想象中夸张——同一台相机、同一个游戏机，Amazon.co.jp、乐天市场、煤炉、Yahoo! Auction 能差出 3000 到 20000 日元。全靠手动开四个标签页对比太蠢了，不如让浏览器替我干这活。 这篇聊聊技术实现：怎么在没 API 的情况下从多个日本电商网站抓价格，以及哪些模式

买安全工具的时候，很多人会陷入"功能军备竞赛"，觉得工具越多越安全。但我踩过不少坑之后发现，这个问题没这么简单——你不只是在买功能，你买的是一种**推理方式**。这个问题不搞清楚，工具越买越多，问题越堆越杂。 Stave 是我参与开发的一个开源项目，下面的讨论中会涉及它，相关的论断我会标出边界。Cynefin 是 Dave Snowden 的框架，后文会展开介绍。 团队在组装云安全工具时总会出