编程

一、为什么需要 SSE？ SSE（Server-Sent Events，服务器推送事件） 是一种基于 HTTP 的单向实时通信协议。与 WebSocket 的全双工不同，SSE 是 服务端 → 客户端 的单向推送，天然适合以下场景： 💬 实时聊天：接收对方发送的消息 🤖 AI 流式输出：ChatGPT 风格的逐字返回 📊 数据看板：实时刷新指标数据 🔔 消息通知：订单状态变更、审核结果推送 相比 WebSocket，SSE 的优势在于： 维度 SSE ✅ SSE ⚠️ 局限 基于 HTTP，天然支持认证、CORS ✅ 单向通信，客户端需另外发请求 自动重连机制（浏览器端） ✅ 浏览器限制最大 6 个并发连接 协议简单，调试方便 ✅ 不支持二进制数据 防火墙友好，不会被拦截 ✅ IE/Edge Legacy 不支持 二、浏览器中的 SSE 长什么样？ 在浏览器中，使用 SSE 非常简单： // 浏览器原生 EventSource —— 就这么简单 const es = new EventSource('/api/events'); // 监听默认消息 es.onmessage = (e) => { console.log('收到消息:', JSON.parse(e.data)); }; // 监听自定义事件 es.addEventListener('chat-message', (e) => { const msg = JSON.parse(e.data); renderMessage(msg); }); // 监听连接状态 es.onerror = () => console.log('连接断开，浏览器会自动重连'); 浏览器的 EventSource API 帮你处理了所有脏活累活： ...

网站： martinfowler.com 站长： Martin Fowler — Thoughtworks 首席科学家，《重构》《企业应用架构模式》作者 创立时间： 2000 年左右，bliki 始于 2003 年 有些网站，你第一次点进去觉得平平无奇，但第二次、第三次之后，它会慢慢变成你查资料时的默认起点。 martinfowler.com 对我来说就是这样的存在。 一个什么样的网站？ 如果用一句话概括，这是一个软件工程的深度内容站。没有广告，没有付费墙，没有"优化阅读体验"的弹窗。就是白底黑字，配上偶尔的代码块和图表。 站长 Martin Fowler 是 Thoughtworks 的 Chief Scientist，写过几本改变行业面貌的书——1999 年的《重构》让"改善既有代码的设计"成为程序员的必修课，2002 年的《企业应用架构模式》给了无数后端开发者一套通用词汇表。 但这不只是他个人的博客。他自己说：“这个网站最开始只是放我自己的文章，但随着它越来越受欢迎，我开始用它帮别人的好文章获得更多曝光。” 于是每篇文章都经过他本人的筛选和编辑——质量远重于数量。这种克制让网站二十多年积累的内容始终保持在一个可被信任的水准上。 Bliki：介于博客和维基之间 2003 年，Fowler 开创了一个叫 bliki 的格式——blog + wiki 的混合体。 普通博客是按时间线排列的，文章写完了就固定了。Wiki 是围绕主题组织的，可以持续更新。Bliki 试图结合两者：每篇文章围绕一个概念展开，像 wiki 词条一样精炼，但又保留作者的视角和叙事。 你去看看他的 Bliki 页面，会看到从 Architecture Decision Record 到 Microservices 再到 Technical Debt 的条目。很多我们日常挂在嘴边的术语，最早的清晰定义就出自这里。 比如 ADR（架构决策记录）——这个如今被广泛采用的实践，他那篇 2026 年 3 月的 bliki 条目就是最好的入门材料之一：简短、清晰、实用，几页纸说清楚为什么要写、怎么写、写多长。 那些改变行业的概念 这个网站是不少行业关键概念的"爆发地"： Microservices（微服务） —— 2014 年，Fowler 和 James Lewis 联合撰写的那篇定义性文章，到现在还是讨论微服务时被引用最多的文献之一。“微服务是一套小型的、自治的服务，每个服务围绕业务能力构建……“这段话就是从这儿来的。 ...

原文： Thoughts on Slowing the Fuck Down — Mario Zechner 发表于 2026 年 3 月 25 日 这是一篇让人读着读着就想拍桌子的文章。 不是因为赞同，而是因为每一段话都在刺痛那些我们都经历过、却假装没看见的东西。 我们都曾以为自己是例外 如果你用过 Cursor、Claude 或任何 AI 编码工具写过一个完整项目，你大概曾经有过这个念头： “这东西效率太高了，我完全可以靠它十倍速产出。” 然后你继续写。一个文件接一个文件。agent 帮你搭架构、写接口、补测试——你像个乐队指挥一样，坐镇中央，挥一挥手就有一排排代码涌现。 你觉得自己是个天才管理者和一名高效产出者。 但作者告诉你一个残酷的事实：你只是把复杂性推迟了。 代理的问题，不是犯错，而是不会学习 文章里有一个比喻很妙：人类也会犯错，但人犯错之后会学习、会痛、会改。如果加班写出一堆屎山代码，半夜两点你会对着屏幕骂自己。 AI agent 不会。它不会痛。 同样的错误，它可以犯一千次，每次都用最新的热情把代码写得更烂一点。因为它的每次调用都是独立的——它没有记忆，没有懊悔，没有「我刚把这段逻辑搞砸了，这次不能再这样」的自我修正。 更致命的是：人类是瓶颈，这恰恰是好事。 一个人一天最多写几百行高质量代码。但一个 agent 可以在几小时内输出两万行。如果人写了烂代码，一天积累的烂东西有限。但如果一个 agent 军团在疯狂输出，那些「无害的小错误」会以指数级的速度叠加，直到有一天你回过头来发现——整个代码库已经没有一块你信任的地方了。 那种「一切都还可控」的幻觉 读这篇文章时，最击中的是这句： You let them run free, and they are merchants of complexity. 我回想了一下过去写的一些 AI 辅助项目。是的，那些代码库确实变得很奇怪。到处都是「看上去像那么回事但总觉得哪里不对劲」的抽象层。有为了一个简单的 CRUD 封装了三层接口的，有在同一段逻辑里同时用了三种设计模式的。 你不敢改，因为看不懂它是怎么拼起来的。你怕一改全崩。 agent 替你搭建了一个自己也不理解的迷宫，而你发现你才是那个被困在里面的人。 那应该怎么办？ 作者的建议不是「别用 AI」，而是慢下来。 这听起来可能是整篇文章里最不性感的建议。没有奇技淫巧，没有很酷的 prompt 模板，也没有所谓的人机协作黄金法则。就是： 慢。下。来。 架构自己画，不要丢给 agent API 设计自己写，agent 可以帮你补实现 设一个每天可接受的 agent 代码量上限——和你自己能真正 review 的能力匹配 该手写就手写，手写带来的摩擦感恰恰是你理解系统的过程 这就像做饭。你可以用预制菜十分钟做出一桌菜，但你永远不会知道食材在锅里发生的变化。有些感觉，跳过了就跳过了，不会再回来。 ...