<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Errors on PlumePHP</title><link>https://plumephp.com/tags/errors/</link><description>Recent content in Errors on PlumePHP</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Sun, 27 Sep 2026 11:00:00 +0800</lastBuildDate><atom:link href="https://plumephp.com/tags/errors/index.xml" rel="self" type="application/rss+xml"/><item><title>GraphQL 错误处理与可观测性：从 errors[] 到链路追踪</title><link>https://plumephp.com/graphql-error-handling/</link><pubDate>Sun, 27 Sep 2026 11:00:00 +0800</pubDate><guid>https://plumephp.com/graphql-error-handling/</guid><description>&lt;p&gt;错误处理是 API 工程中最容易被低估的部分。REST 时代我们用 HTTP 状态码表达错误，但 GraphQL 的响应永远是 200——错误被结构化地放在 &lt;code&gt;errors[]&lt;/code&gt; 数组里。这种设计更优雅，也更容易被做坏：要么所有错误都返回一段&amp;quot;Error: something went wrong&amp;quot;，要么把内部堆栈直接抛给客户端。本文讲解如何建立一套从错误模型、错误码、到日志与链路追踪的完整错误处理体系，让 GraphQL 服务的错误既可诊断、又对客户端友好。&lt;/p&gt;</description></item></channel></rss>