如何写好设计文档？

鸟窝 2026-06-23 08:40:18 累计浏览 29 次

本机暂存

内容概览

本文基于Go官方proposal仓库中的五个优秀设计文档，提炼其共性结构与写作方法，形成一份可复用的设计文档写作指南。Go设计文档以朴素语言讨论重要取舍，让陌生读者快速理解问题、方案及原因。总结出的通用模板包括元信息、摘要概述、背景动机、设计提案、理由取舍、兼容性、实现过渡计划和附录等部分。关键点包括：标题用一句话说清做什么；摘要埋下最重要承诺；背景动机用具体代码示例说明痛点，让读者‘疼’起来；设计提案采用渐进式教学，配Go声明和代码示例，明确边界；理由取舍主动对比备选方案，解释‘为什么不是别的’；兼容性诚实承认代价，提供渐进迁移路径；实现计划用数据和工具支撑可落地性；附录后置完整API和FAQ。文章强调设计文档应注重可读性、实用性和长期价值，适用于软件工程师和技术负责人参考。

写好一篇设计文档并不是一件容易的事情，本文从 Go 官方 proposal 仓库（<a href="https://github.com/golang/proposal/tree/master/design">golang/proposal/design</a>）中挑选了几个公认优秀、影响深远的设计文档，提炼它们的共性结构与写法，总结成一份可复用的设计文档写作指南，并精炼成一个 <code>to-design</code> skill。<h2 id="为什么参考-Go-的设计文档"><a href="#为什么参考-Go-的设计文档" class="headerlink" title="为什么参考 Go 的设计文档"></a>为什么参考 Go 的设计文档</h2>Go 的设计文档（design proposal）是工程界公认的高质量范本：它们用最朴素的语言讨论最重要的取舍，几乎不堆砌术语，却能让一个陌生读者在十分钟内理解"要解决什么问题、方案长什么样、为什么是这个方案而不是别的"。本文参考的 5 个文档：<table><thead><tr><th>文档</th><th>主题</th><th>价值</th></tr></thead><tbody><tr><td><a href="https://github.com/golang/proposal/blob/master/design/43651-type-parameters.md">43651-type-parameters</a></td><td>泛型（Go 1.18）</td><td>Go 史上最大的语言变更，复杂特性如何讲清楚的典范</td></tr><tr><td><a href="https://github.com/golang/proposal/blob/master/design/29934-error-values.md">29934-error-values</a></td><td>错误包装 <code>%w</code>/<code>errors.Is</code>/<code>As</code>（Go 1.13）</td><td>标准库 API 设计的范本</td></tr><tr><td><a href="https://github.com/golang/proposal/blob/master/design/60078-loopvar.md">60078-loopvar</a></td><td>循环变量作用域（Go 1.22）</td><td>破坏性变更如何论证兼容性的范本</td></tr><tr><td><a href="https://github.com/golang/proposal/blob/master/design/56345-structured-logging.md">56345-structured-logging</a></td><td>结构化日志 <code>log/slog</code></td><td>新增包的设计与目标论证范本</td></tr><tr><td><a href="https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md">32437-try-builtin</a></td><td><code>try</code> 内建函数（被否决）</td><td>即使被否决，也是讲透取舍的范本</td></tr></tbody></table><hr><h2 id="共性结构：一份设计文档的标准骨架"><a href="#共性结构：一份设计文档的标准骨架" class="headerlink" title="共性结构：一份设计文档的标准骨架"></a>共性结构：一份设计文档的标准骨架</h2>把这 5 个文档的章节排在一起，会发现它们高度收敛到同一套骨架。下面是综合提炼出的通用模板，每一节都说明它要回答的问题。<img src="/images/image-20260622225437072.png"><h3 id="标题-作者-日期-状态（Title-Author-Date-Status）"><a href="#标题-作者-日期-状态（Title-Author-Date-Status）" class="headerlink" title="标题 / 作者 / 日期 / 状态（Title / Author / Date / Status）"></a>标题 / 作者 / 日期 / 状态（Title / Author / Date / Status）</h3>开头永远是元信息。Go 的写法极简：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 3 4 </pre></td><td class="code"><pre>Title: Proposal: Go 2 Error Inspection Authors: Jonathan Amsterdam, Russ Cox, Marcel van Lohuizen, Damien Neil Last updated: January 25, 2019 Discussion at golang.org/issue/29934 </pre></td></tr></table></figure><blockquote>关键点：标题用一句话说清"做什么"（"A built-in Go error check function, <code>try</code>"），并且永远附上讨论入口链接（issue 号），让文档不是孤立的。</blockquote><h3 id="摘要-概述（Abstract-Summary）"><a href="#摘要-概述（Abstract-Summary）" class="headerlink" title="摘要 / 概述（Abstract / Summary）"></a>摘要 / 概述（Abstract / Summary）</h3>一段话讲完全文。读者读完这一段，应该已经知道你要做什么、大致怎么做。泛型文档的摘要开门见山，一句话定义要做的事，紧接着埋下最重要的承诺：<blockquote>We suggest extending the Go language to add optional type parameters to type and function declarations. ... The design is fully backward compatible with Go 1.</blockquote>错误处理文档的摘要则点明改动范围和目标：<blockquote>We propose several additions and changes to the standard library's <code>errors</code> and <code>fmt</code> packages ... codifying error wrapping ...</blockquote><blockquote>关键点：摘要里就要埋下最重要的承诺（如 "fully backward compatible with Go 1"），它往往是整个设计的隐含约束。</blockquote><h3 id="背景-动机（Background-Motivation）"><a href="#背景-动机（Background-Motivation）" class="headerlink" title="背景 / 动机（Background / Motivation）"></a>背景 / 动机（Background / Motivation）</h3>用具体的、可感的例子说明"痛在哪"，而不是抽象地说"现状不好"。这是 Go 文档最值得学的一点。<img src="/images/image-20260622225601361.png">循环变量文档没有讲理论，而是直接甩出一段 bug 代码——往切片里 append 十次 <code>&i</code>，结果十个指针全指向最终值：<blockquote>Briefly, the problem is that loops like this one don't do what they look like they do:<figure class="highlight go"><table><tr><td class="gutter"><pre>1 2 3 4 </pre></td><td class="code"><pre>var ids []*int for i := 0; i < 10; i++ { ids = append(ids, &i) } </pre></td></tr></table></figure>That is, this code has a bug. After this loop executes, <code>ids</code> contains 10 identical pointers, each pointing at the value 10, instead of 10 distinct pointers to 0 through 9.</blockquote>接着扩展到闭包打印 "3, 3, 3"、表驱动测试 <code>t.Parallel</code> 全部只测了最后一个 case，最后用一句话给这个设计定性：<blockquote>Loop variables being per-loop instead of per-iteration is the only design decision we know of in Go that makes programs incorrect more often than it makes them correct.</blockquote>错误处理文档则点明痛点的普遍性——错误包装已经无处不在，普遍到值得收进标准库，同时坦白它的代价：<blockquote>... one pattern has become so pervasive that we feel it is worth enshrining in the standard library ...... indiscriminate wrapping can expose implementation details, introducing undesired coupling between packages ...</blockquote><blockquote>关键点：先让读者"疼"起来，方案才有说服力。用真实代码、真实场景，而不是形容词。</blockquote><h3 id="设计-提案（Design-Proposal）"><a href="#设计-提案（Design-Proposal）" class="headerlink" title="设计 / 提案（Design / Proposal）"></a>设计 / 提案（Design / Proposal）</h3>文档的主体。共性写法：<ul><li>从简单到复杂，渐进式教学。泛型文档从 <code>Print</code> 这种最简单的例子起步，逐步引到泛型图、<code>Map</code>、约束类型推导等复杂场景；它甚至专门提醒读者别把这里的 "generic" 和别的语言混为一谈：<blockquote>Don't confuse the term generic as used in this design with the same term in other languages like C++, C#, Java, or Rust ...</blockquote>它把约束定位为"显式定义的结构化约束"，而非声明式子类型：<blockquote>Type constraints are interface types. ... explicitly defined structural constraints.</blockquote></li><li>每个 API 都配 Go 声明 + 代码示例。slog 文档对 Logger/Record/Handler 三个核心类型，先给声明再给用法片段（如何用 <code>slog.Group</code> 分组、如何用 <code>LogValuer</code> 脱敏密码）。它对成功的定义也落在"一次安装、处处生效"上：<blockquote>... the application can create a single handler and install it once for each logging library ... the benefits of a unified backend can be obtained with minimal code churn.</blockquote></li><li>对照"改造前 vs 改造后"。<code>try</code> 文档把多行 <code>if err != nil</code> 和一行 <code>f := try(os.Open(filename))</code> 并排展示，收益一目了然。</li><li>明确边界和约束。<code>try</code> 文档明确说明：只能在最后返回值为 <code>error</code> 的函数里用、<code>go try(f)</code>/<code>defer try(f)</code> 禁用。划清范围本身就是设计的一部分。</li></ul><img src="/images/image-20260622225925946.png"><blockquote>关键点：声明 + 示例 + 边界三件套。能用一段可运行代码说明的，绝不用一段文字描述。</blockquote><h3 id="理由-取舍（Rationale）"><a href="#理由-取舍（Rationale）" class="headerlink" title="理由 / 取舍（Rationale）"></a>理由 / 取舍（Rationale）</h3><blockquote>Rationale 直译是"理由、根据"，在设计文档里特指 "为什么是这个方案，而不是别的"的论证 。它和"设计"那一节不同：设计讲"方案长什么样"，Rationale 讲"为什么这么选"——尤其是对比备选方案、解释取舍。</blockquote>这是区分"好文档"和"平庸文档"的关键章节：解释"为什么是这个方案，而不是别的"。<img src="/images/image-20260622225728666.png">好的 Rationale 会主动暴露被放弃的方案及原因。<code>try</code> 文档的 "Design iterations" 一节完整记录了取舍路径——早期版本带一个用户自定义错误处理器，后来被砍掉：<blockquote>... the context-sensitivity of <code>try</code> was considered fraught ...... in the current iteration, rather than introducing a second built-in, we decided to remove the dual semantics of <code>try</code>.</blockquote>错误处理文档同样解释了演进中改变的选择：为什么用 <code>%w</code> 显式 opt-in 包装，而不是默认包装——因为默认包装会泄露被包装的类型：<blockquote>... doing so would effectively change the exposed surface of a package by revealing the types of the wrapped errors ...... we require that programmers opt in to wrapping by using the new formatting verb <code>%w</code>.</blockquote>泛型文档甚至专门有 "Discarded ideas"（被丢弃的想法）小节，第一条就是 "What happened to contracts?"——坦白早期草案用过一个叫 contracts 的语言构造，后来换成了接口类型：<blockquote>An earlier draft design of generics implemented constraints using a new language construct called contracts.Type sets appeared only in contracts, rather than in interface types.</blockquote><blockquote>关键点：主动写"我们没选什么、为什么没选"。这比只论证你选的方案更有说服力，也帮后人避免重复讨论。</blockquote><h3 id="兼容性（Compatibility）"><a href="#兼容性（Compatibility）" class="headerlink" title="兼容性（Compatibility）"></a>兼容性（Compatibility）</h3>凡涉及破坏性变更，必须正面回应兼容性。循环变量文档是这方面的范本——它干脆把兼容性和 rationale 合成一节，开门见山地承认"这是破坏性变更"：<blockquote>In most Go design documents, Rationale and Compatibility are two distinct sections. For this proposal, considerations of compatibility are so fundamental that it makes sense to address them as part of the rationale. To be completely clear: this is a breaking change to Go.</blockquote>然后用三个机制把破坏性降到最低，并保证老代码原样运行：<blockquote>... it only applies the new semantics to new programs, so that existing programs are guaranteed to continue to execute exactly as before.</blockquote><ul><li>通过 <code>go.mod</code> 里的 <code>go</code> 版本行按模块 opt-in。</li><li>用 <code>//go:build</code> 支持按文件逐步迁移（gradual code repair）。</li><li>把破例（打破"语言不重定义"的通则）说明为一次性的、深思熟虑的例外，理由是循环变量是 Go 里唯一一个"让程序错的次数多于对的次数"的设计。</li></ul>错误处理文档则简洁声明：变更不违反 Go 1 兼容性承诺，同时诚实指出两处代价：<blockquote>Gathering frame information may slow down <code>errors.New</code> slightly, but this is unlikely to affect practical programs.Errors constructed with <code>errors.New</code> and <code>fmt.Errorf</code> will display differently with <code>%+v</code>.</blockquote><blockquote>关键点：诚实。承认代价（性能、行为变化），给出渐进迁移路径，用先例佐证。</blockquote><h3 id="实现-过渡计划（Implementation-Transition）"><a href="#实现-过渡计划（Implementation-Transition）" class="headerlink" title="实现 / 过渡计划（Implementation / Transition）"></a>实现 / 过渡计划（Implementation / Transition）</h3>如何落地、分几步、配套什么工具。<ul><li>错误处理文档：发布 <code>golang.org/x/xerrors</code> 兼容老版本，计划在 Go 1.13 周期初落地。</li><li>循环变量文档：提供静态编译标志和动态二分工具，并用 Google 内部全量启用的实测数据支撑"风险可控"——失败率约 1/8000，且几乎都是本就有 bug 的测试：<blockquote>We have used this dynamic tooling in a conversion of Google's internal monorepo to the new loop semantics. The rate of test failure caused by the change was about 1 in 8,000.</blockquote>它还配了两个工具：静态标志 <code>-d=loopvar=2</code> 报告受影响的循环，动态工具 <code>bisect</code> 用二分法定位出问题的具体那一行。</li></ul><blockquote>关键点：用数据和工具支撑"可落地"。Google 内部实测数据让"风险可控"从口号变成事实。</blockquote><h3 id="附录（Appendix）：完整-API-示例-FAQ"><a href="#附录（Appendix）：完整-API-示例-FAQ" class="headerlink" title="附录（Appendix）：完整 API / 示例 / FAQ"></a>附录（Appendix）：完整 API / 示例 / FAQ</h3>把会打断主线阅读的细节后置：<ul><li>slog 文档用附录放完整的包文档（含 <code>TextHandler</code>/<code>JSONHandler</code> 输出样例）。它在正文里讨论 Level 取值时，把背后的三条约束讲得很透——这种"看似随意的数字其实每一个都有理由"的写法值得学：<blockquote>Since Levels are ints, Info is the default value for int, zero.（Info=0，是 int 零值，做默认级别最自然）Negating a verbosity converts it into a Level.（用取负兼容 verbosity 风格的日志库）Our gap of 4 matches OpenTelemetry's mapping.（级别间隔 4，对齐 OpenTelemetry）</blockquote></li><li><code>try</code> 文档用 FAQ 回应高频质疑，比如"为什么不用 Rust 的 <code>?</code>"和"<code>try</code> 和异常处理有何不同"：<blockquote>Go has been designed with a strong emphasis on readability ... using <code>?</code> would introduce a new post-fix operator into the language.<code>try</code> is simply syntactic sugar ... There is also no mechanism to "catch" an error. ... In summary, <code>try</code> is a shortcut for a conditional <code>return</code>.</blockquote></li></ul><blockquote>关键点：主线保持流畅，细节进附录/FAQ。</blockquote><hr><h2 id="一页纸模板（可直接复制）"><a href="#一页纸模板（可直接复制）" class="headerlink" title="一页纸模板（可直接复制）"></a>一页纸模板（可直接复制）</h2><figure class="highlight markdown"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 </pre></td><td class="code"><pre>Title: Proposal: <一句话说清做什么> Author(s): <作者> Last updated: <日期> Discussion at <issue / 讨论链接> ## Abstract <一段话讲完全文：做什么、大致怎么做、最重要的承诺> ## Background / Motivation <用具体代码/场景说明痛点。让读者先"疼"起来> ## Design / Proposal <从简单到复杂的渐进示例> <每个 API：Go 声明 + 用法片段> <改造前 vs 改造后对照> <明确边界与约束> ## Rationale（理由 / 取舍） <为什么是这个方案> <被放弃的备选方案 + 放弃原因> ## Compatibility <是否破坏性变更，代价是什么，如何渐进迁移> ## Implementation / Transition <落地步骤、配套工具、实测数据> ## Appendix (可选) <完整 API / 端到端示例 / FAQ> </pre></td></tr></table></figure><hr><h2 id="写法上的-7-条核心原则"><a href="#写法上的-7-条核心原则" class="headerlink" title="写法上的 7 条核心原则"></a>写法上的 7 条核心原则</h2>把这 5 个文档的"气质"提炼成可执行的原则：<ol><li>标题就是结论。一句话说清做什么，附讨论链接。</li><li>痛点用代码说，不用形容词说。真实 bug、真实场景最有说服力（见循环变量文档的 <code>&i</code> 例子）。</li><li>渐进式教学。从最简单的例子起步，复杂概念留到读者有了直觉之后再讲（见泛型文档）。</li><li>声明 + 示例 + 边界三件套讲 API。能跑的代码胜过一段描述。</li><li>主动暴露被否决的方案。"我们没选 X，因为 Y" 比单方面论证更可信，也避免后人重复讨论（见 <code>try</code> 的 Design iterations、泛型的 Discarded ideas）。</li><li>诚实面对代价。性能变慢、输出变化、破坏兼容——都明说，再给迁移路径和先例（见循环变量、错误处理文档）。</li><li>用数据和工具证明可落地。Google 内部实测的 "1/8000 失败率"，比任何"我们认为风险可控"都管用。</li></ol><img src="/images/image-20260622230128194.png"><hr><h2 id="文本风格：句子、主语与段落怎么写"><a href="#文本风格：句子、主语与段落怎么写" class="headerlink" title="文本风格：句子、主语与段落怎么写"></a>文本风格：句子、主语与段落怎么写</h2>结构是骨架，文本风格是肌肉。把这 5 个文档逐句拆开看，会发现它们的"文风"也高度一致——而且每一条都可直接照搬。<img src="/images/image-20260622230748179.png"><h3 id="主语：决策用-We-，行为用-代码本身-，说理用-you"><a href="#主语：决策用-We-，行为用-代码本身-，说理用-you" class="headerlink" title="主语：决策用 "We"，行为用"代码本身"，说理用 "you""></a>主语：决策用 "We"，行为用"代码本身"，说理用 "you"</h3>Go 文档的人称切换很有讲究：<ul><li>讲团队的决策和取舍，主语是 "We"。它把设计说成一群人共同的、可负责的选择，而非客观真理：<blockquote>We propose several additions and changes ...... we decided to remove the dual semantics of <code>try</code>.</blockquote></li><li>讲代码的行为，主语是代码自己。让读者把注意力放在程序而非作者身上：<blockquote>... this code has a bug.... loops like this one don't do what they look like they do.</blockquote></li><li>讲读者会遇到的情况，直接用 "you"，像面对面解释：<blockquote>Once you have a test that fails with the new semantics but passes with the old semantics, you run: <code>bisect ...</code></blockquote></li></ul><blockquote>关键点："We" 担责、代码当主角、"you" 拉近距离。避免"It is suggested that..."这类没有主语、推卸责任的被动腔。</blockquote><h3 id="句子：短句下结论，长句讲机制"><a href="#句子：短句下结论，长句讲机制" class="headerlink" title="句子：短句下结论，长句讲机制"></a>句子：短句下结论，长句讲机制</h3>Go 文档的节奏感来自长短句交替：先用一个极短的句子拍板，再用长句铺开依据。循环变量文档最典型——先甩代码，紧接一句话定性，短到不能再短：<blockquote>That is, this code has a bug.</blockquote>下结论时句子短、语气硬（"this is a breaking change to Go"）；一旦要解释"为什么不会出问题"，就换成信息密集的长句，把条件、机制、后果一次说清：<blockquote>... it only applies the new semantics to new programs, so that existing programs are guaranteed to continue to execute exactly as before.</blockquote><blockquote>关键点：判断用短句，论证用长句。短句负责让读者记住结论，长句负责让结论站得住。不要通篇都是绕来绕去的长句。</blockquote><h3 id="段落：一段一个论点，结论先行"><a href="#段落：一段一个论点，结论先行" class="headerlink" title="段落：一段一个论点，结论先行"></a>段落：一段一个论点，结论先行</h3>最值得学的是循环变量文档的 Rationale——它的每个三级小标题本身就是一个完整的论点句，段落只是展开论证：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 3 </pre></td><td class="code"><pre>### A decade of experience shows the cost of the current semantics ### Old code is unaffected, compiling exactly as before ### Changing the semantics is usually a no-op, and when it's not, it fixes buggy code far more often than it breaks correct code </pre></td></tr></table></figure>读者光看标题就能读完整条论证链。每段内部也遵循"结论先行"：段首一句给出观点，后面才是例子和数据。<blockquote>关键点：一段只讲一件事，观点放段首。标题能写成一句话的论点，就别写成名词短语（写 "Old code is unaffected" 而不是 "Compatibility"）。</blockquote><h3 id="语气：克制的诚实，甚至自嘲"><a href="#语气：克制的诚实，甚至自嘲" class="headerlink" title="语气：克制的诚实，甚至自嘲"></a>语气：克制的诚实，甚至自嘲</h3>Go 文档不端着。承认代价时直接说 "may slow down <code>errors.New</code> slightly"；讲到这个 bug 多普遍时，作者连自己都不放过：<blockquote>Russ certainly has done it repeatedly over the past decade, despite being the one who argued for the current semantics and then implemented them. (Apologies!)</blockquote>这种"作者本人也踩过坑"的坦白，比任何"此问题影响重大"的形容词都更有说服力。<blockquote>关键点：用事实和自嘲建立可信度，不用形容词堆砌权威感。强调要克制——<code>_this is a breaking change_</code> 全文就斜体强调这一处，反而格外醒目。</blockquote><hr><h2 id="反面提醒：即使被否决，文档也要写好"><a href="#反面提醒：即使被否决，文档也要写好" class="headerlink" title="反面提醒：即使被否决，文档也要写好"></a>反面提醒：即使被否决，文档也要写好</h2><code>try</code> 提案最终被社区否决了，但它的设计文档依然是范本——因为它把每一个取舍都讲透了。文档的价值不取决于提案是否通过，而取决于它是否让讨论变得高质量。 一份好的设计文档，哪怕方案最后没被采纳，也会成为后人理解"这条路为什么走不通"的权威参考。<img src="/images/image-20260622230957656.png"><blockquote>写设计文档的终极目的不是"说服别人同意你"，而是"让所有人在同一个事实和取舍基础上做决定"。</blockquote><h2 id="培养软实力和编写捷径"><a href="#培养软实力和编写捷径" class="headerlink" title="培养软实力和编写捷径"></a>培养软实力和编写捷径</h2>看到这里，你已经了解了写好设计文档的一些思路和方法，你可以审视自己以前写的文档，也可以思考和动手写一篇新的设计文档验证自己的思路。AI时代，我们可以让大模型遵循上面的指导原则，帮助我们来写设计文档，可以极大的减少我们的工作量。设计文档是给程序员看的，而SPEC是给智能体看的。我在<a href="https://goal.rpcx.io/">goal-workflow</a> AI开发流程中增加一个 <code>to-design</code>技能，它可以根据PRD（需求文档， <code>prd</code> 生成）生成设计文档。比如昨天我给rpcx增加了一个新特性，使用 <code>gordma</code> 库替换原先的不成熟的<code>rsocket</code>库，以便让rpcx这个框架支持RDMA通讯，生成的设计文档如下：<a href="https://github.com/smallnest/rpcx/blob/master/tasks/design-rdma-conn-transport.md">https://github.com/smallnest/rpcx/blob/master/tasks/design-rdma-conn-transport.md</a> , 生成的这个设计文档颇具Go团队的风格，而且设计思路非常的清晰全面。<img src="/images/image-20260622231932970.png">

同分类推荐文章

Designing With Uncertainty: How AI Supercharges Probabilistic Thinking （2026-06-16 23:00:00）
The Benefits Of Cognitive Inclusion In UX Research （2026-06-10 18:00:00）
Day for Night （2026-05-29 17:57:14）

查看更多设计文章 →

建议继续学习

哪本书是对程序员最有影响、每个程序员都该阅读的书？（累计阅读 15,096）
看源代码那些事（累计阅读 10,577）
最常被程序员们谎称读过的计算机书籍（累计阅读 9,139）
腾讯抄你肿么办（累计阅读 7,734）
低级程序员和高级程序员的区别（累计阅读 5,786）
从代码看不同层次程序员的进化（累计阅读 5,647）
领导如何应对员工离职（累计阅读 5,471）
对程序员职业的一些建议（累计阅读 5,092）
如何设计一个优秀的API （累计阅读 4,854）
IE的Get请求(URL)的最大长度限制（累计阅读 4,833）