Prisma 配置失误让查询慢了 4 倍
Prisma's pgbouncer=true on Supabase made every query 4 round-trips (postmortem)
我们的预订系统在六个月内一直遭受性能拖累，直到发现一个隐蔽的配置错误。原本以为是 Helsinki 到 Dublin 的网络延迟问题，结果发现是 Prisma 在 Supabase 的 Supavisor 上错误启用了 pgbouncer=true 模式。这导致每个数据库查询都要额外执行 BEGIN、DEALLOCATE ALL 和 COMMIT，使得单次查询变成了四次网络往返。修正这一行配置后，页面响应时间从 8 秒骤降至 1.88 秒。这次经历让我明白，当成本不随负载变化时，往往是调用开销而非计算问题在作祟。
算术通常是正确的，但代理分析中附加的句子在缺乏实测数据支撑前都只是猜测。
HN 评论区
10- ProjectBarks
最让人难受的是，修复方案其实早就有了：Claude Code，Anthropic 推出的命令行代码代理。
这篇文章听起来本该极其精彩，但行文风格实在让人倒胃口。
> "先在 staging 环境部署，然后在 23:40 部署到生产环境"
读者为什么需要知道精确到分钟的详细时间线？
- OG_BME
不幸的是，这完全是由 AI 写的。
- tecleandor
致作者：
首先，你依然有图片问题（以及其他问题）。加载你的主页大约需要下载 60MB 数据，其中包括自动加载的 40MB MP4 文件。降低分辨率并压缩吧。你不需要用手机复现这个问题，只需打开浏览器的开发者工具并刷新页面，就能看到它有多重。另外，内存使用量的计算也是错的，但这不重要，因为这很可能是 LLM 算出来的。
其次，karibukit.com 上的 API 挂了。
别太依赖 LLM。用你自己的眼睛去检查。