最近在微服务开发中遇到一个非常危险的问题。 我们使用 echo 框架，在 handler 中通过 errgroup 启动 goroutine，结果 goroutine 内发生 panic。即使我们添加了 Recover 中间件来保护服务进程，服务依然直接崩溃，并导致其他请求同一服务器的用户请求被中止。

Recently, during microservice development, I encountered a very dangerous issue. We were using the echo framework, and in a handler, we launched a goroutine via errgroup. However, when a panic occurred inside that goroutine, even though we had added the Recover middleware to protect the service process, the entire service still crashed, causing all users sharing the same server to have their requests aborted.

如今，越来越多的工程团队会在 API 交付的环节中使用 OpenAPI（Swagger）来生成接口文档。通常的交付形式是：一个 yaml 格式的 spec 文件，加上 Swagger UI 的bundle，然后混在一堆js文件中变成一个zip压缩包邮件发送给用户。所以毫不意外的，我们会发现，实际工作中这些文档往往不准确、不完整，滞后于代码的——它们常常是项目最后阶段赶工的成果物。

Nowadays, more and more engineering teams use OpenAPI (Swagger) to generate API documentation during the API delivery process. The typical delivery format is: a yaml spec file, bundled with Swagger UI, mixed with a bunch of js files, and then compressed into a zip file to be emailed to users. Unsurprisingly, in practice, these documents are often inaccurate, incomplete, and lag behind the code—they are usually rushed deliverables created in the final stages of a project.

最近，LLM 与 OpenAI 非常流行， 相信很多人从 Complete 和 Chat API 中的 stream 模式第一次接触到了 SSE API。SSE(Server-Sent Events)是一种支持从 Server Side 向 Client Side 推送事件的方式。它与传统的 Restful API 不同，传统的 Restful 架构只能从服务器端发起请求，然后客户端返回响应的方式进行数据传输。在需要实时更新数据的场景中，只能依赖轮询或者异步任务机制来实现。但前者性能不高，而后者会增加前后端架构的复杂性。