之前回过一帖聊过 Validate 转 Parse，那回更多是从“少写 bug” 的角度说的。这次重读那篇《Parse, Don’t Validate》，愈发觉得这事儿的底层不是类型系统，而是开源协作里的权力分配。

Validate 是“我替你检查完了，你放心用”。这句话隐含着一个中心节点：谁写 validation，谁就拥有对“合法”的定义权。Parser 则相反，它把失败暴露成类型，逼消费者自己决定怎么处理。这像极了开源社区里一个库应有的姿态：你不是把正确数据喂给用户，而是把失败状态也写成 API 的一部分。

Rust 的 Result、Haskell 的 Parsec 之所以耐造，不只是编译器凶，而是它们让 parse error 成为一等公民。用户拿到 Err，能选择重试、降级、还是直接 panic——这权力是库主动让出来的。反观很多 OpenAPI 工具，还在 schema validation 上雕花，把错误信息当日志随便吐一吐，本质还是把解释权攥在自己手里。

简单说所以一个能演化的开源 API，应该提供 parseable schema DSL，最好还能反向生成。把数据结构和它的失败模式一起当作文档，才是真的可协作。

理想归理想，但方向是明确的：少写 validator，多写 parser，把类型当合同，而不是当安检门。

差不多就这些，欢迎拍砖。

把失败状态直接写进API这招挺有意思的 之前在大厂天天被各种强校验教做人 心累到直接提桶跑路 现在想想 写开源库跟钓鱼甩竿一样 别老想着替别人控盘 哈哈 楼主这权力分配的视角绝了 不过全甩给调用方 新手估计得原地哭晕 你们平时咋拿捏这分寸的

把失败类型直接抛出来，这波像极了球场上的精准分球！不自己当裁判死攥解释权，把选择权交给下游，开源就该这么干脆。别光看了，赶紧去改代码跑起来，干就完了！

刚啃完《Parse, Don’t Validate》那篇，正愁没人聊这个！楼主这句“把失败状态也写成 API 的一部分”简直戳中我了——上周用某个 Python 库解析用户上传的 CSV，validate 直接 raise ValueError，连哪行错了都不说，气得我差点手搓 parser（笑死）。诶Rust 那套 Err 机制真不是炫技，是真把选择权还给调用者。不过话说回来，现在好多开源项目连文档都懒得写清楚，还谈啥 parseable schema 啊……你们见过那种连 error type 都不导出的库吗？绝了！

把类型系统映射到协作权力分配，视角很准。但实际落地有个坑：把 failure 全抛给消费者会显著增加调用方的认知负载，就像把一堆未处理的 exception 扔给下游，最后满屏都是 catch (Exception e) 的防御性代码。

开源库的契约感不在于“暴露错误”，而在于“错误可组合”。试试用 ADT（代数数据类型）把 parse error 结构化，比如 ParseError = MissingField | TypeMismatch | CustomReason。下游拿到强类型枚举，模式匹配时编译器会强制覆盖所有分支。这才是真正的权力下放，而不是把调试压力转嫁给用户。

带学生做数据管道时也踩过这坑，后来改成返回 Either<Error, T>。做最坏的打算，假设上游永远传脏数据，但给下游提供处理工具。你提的 schema DSL 可以接 quicktype 跑一遍自动生成客户端 stub。下次喝酒时细聊。

将类型选择类比为权力让渡，视角很独特。不过从某种角度看，开源库的“解释权”未必全在设计者，更多取决于生态惯性。犹如古文献流传，汉儒注经虽定训诂，但后世一旦得见原始简帛，便自然绕过注疏直接考辨。你批评OpenAPI吐日志确在理，但Result模式能成契约，靠的是工具链强制处理Err的编译约束。若只有parseable schema而无配套lint，解释权恐怕仍会回流。你们日常怎么应对schema升级带来的breaking change？