KEEP 详解：Kotlin 语言的演进提案机制
用 Kotlin 的人每天都在吃协程、密封接口、value class 这些特性的红利，但很少有人想过：一个语言特性从"想法"到"落地"要走什么流程？答案就是 Kotlin/KEEP——Kotlin Evolution and Enhancement Process（Kotlin 演进与增强流程）。它是 JetBrains 官方维护的提案仓库，每一份 KEEP 文档就是一个语言特性或标准库变更的设计方案，协程、契约、上下文接收者都从这里走过。本文拆解它是什么、提案怎么流转、有哪些值得读的经典提案，以及普通开发者如何参与。
1、KEEP 是什么
KEEP 是 Kotlin 语言与标准库的官方提案仓库：设计文档放这里公开评审，实现代码则在 JetBrains 的 Kotlin 主仓库完成。每份提案俗称一个 KEEP，编号从 0001 顺延。
仓库结构：
- proposals 目录：完整的设计提案，文件名形如 KEEP-xxxx-标题.md
- notes 目录：设计笔记——尚未成型、正在探索用例与语法兼容性的点子
- resources 与脚本：如校验编号唯一性的 check-uniq-keep-ids.kts
- Apache 2.0 协议，行为准则与 README 说明流程
定位一句话：
- KEEP 管"设计"，YouTrack 管"想法入口"，Kotlin 主仓库管"实现"
2、提案如何流转：三步公开评审
每份 KEEP 都走同一条公开透明的路径，社区全程可见、可参与。
三步流程：
1. 发布：提案获得顺序编号（上一个编号加一），Markdown 文件以 KEEP-xxxx- 为前缀合入 main 分支
2. 公开评审：立即开一个 GitHub Discussion 帖，邀请社区提意见
3. 最终决定：标记为接受（Accepted）、拒绝（Declined）或返回打磨；文档头部常链接对应的 YouTrack 议题
常见状态标记：
- Public discussion（公开讨论中）、In progress（进行中）
- Experimental in 2.0.0 / Stable in 2.1.0（按版本标注实验与转正）
- Declined（拒绝）、Superseded by KEEP-xxxx（被新提案取代）
3、值得读的经典提案
翻一遍 proposals 目录，就是一部 Kotlin 语言进化史。以下这些编号值得记住。
已落地的里程碑：
- KEEP-0164-coroutines：协程，改变 Kotlin 并发范式的奠基提案
- KEEP-0104-inline-classes：内联类，后演进为 value class
- KEEP-0226-sealed-interface-freedom：密封接口，让密封层级跨越模块
- KEEP-0233-jvm-records 与 KEEP-0340-multi-field-value-classes：与 Java 记录类及多字段值类的互操作
仍在演进的争论：
- KEEP-0139-kotlin-contracts：契约，长期实验、覆盖面收窄
- KEEP-0259-context-receivers 与 KEEP-0367-context-parameters：上下文接收者到上下文参数的方案更替
- KEEP-0371-guards：when 分支守卫条件；KEEP-0416-collection-literals：集合字面量
- KEEP-0442-dfa-exhaustiveness：数据流分析驱动的穷尽检查
4、一个特性的完整生命轨迹
以一个特性为例，把流程串起来看。
以 value class 为例的五步：
1. 社区在 YouTrack 提出用例痛点（类型安全又不付出对象开销）
2. 团队立项 KEEP-0104（inline classes），写清用例、语法与兼容影响
3. GitHub Discussion 公开评审，社区反馈边界场景
4. 实验版本落地（Experimental），收集真实项目使用数据
5. 转 Stable，语义沉淀；后续扩展另立 KEEP-0340（多字段值类）继续演进
这份轨迹说明：Kotlin 的每个语法糖背后，都有一份可追溯的公开设计文档。
5、开发者如何参与
KEEP 机制对普通开发者完全开放，但入口有讲究——不能直接提 PR 交新提案。
参与方式：
- 有新想法：去 YouTrack 的 Language Design 子系统提议题，重点写清真实使用场景
- 有倾向：给已有 YouTrack 议题投票、评论——官方明说真实用例是最有价值的社区反馈
- 讨论中提案：去对应的 GitHub Discussion 帖发言
- 已合入提案：欢迎 PR 修正文字错漏
跟踪渠道：
- 新提案公告发在 Kotlin Slack 的 language-proposals 频道
- Discussions 的 RSS 订阅可自动收到新讨论
6、KEEP 与同类机制对比
提案驱动演进并非 Kotlin 独有，各大语言都有自己的 RFC/PEP 机制。
机制对比：
- Python 的 PEP：最老牌，编号文化与 KEEP 最像，但新提案可直接提交草案
- Rust 的 RFC：同样 GitHub 公开评审，流程比 KEEP 更重、阶段更细
- KEEP 的差异点：入口收在 YouTrack（先攒用例再立项），避免提案泛滥；文档 + Discussion 双轨公开
对使用者的意义：
1. 想预判语言走向，读 KEEP 比读新闻更准——状态标记直接对应版本
2. 团队技术选型时，查一下相关 KEEP 的状态（实验 / 稳定 / 被取代）再决定采用度
3. 面试与分享时，能讲清某特性"为什么这样设计"的原始文档就在 KEEP
7、总结
KEEP 是 Kotlin 官方的语言演进提案机制：proposals 目录存放编号设计文档，notes 收纳探索性笔记；每份提案经发布编号、GitHub Discussion 公开评审、最终裁决三步流转，状态从 Public discussion 到 Experimental 再 Stable 全程可追溯。协程（0164）、契约（0139）、上下文接收者（0259）等语言关键特性的来龙去脉都能在这里找到原始设计。参与入口在 YouTrack 的 Language Design，真实用例是最有力的投票。
对于 Kotlin 开发者：把 KEEP 当作语言的"立法档案"——升级前查一眼所用特性的 KEEP 状态，评估实验特性的采用风险；预判语言方向时读正在讨论的提案。理解 KEEP，就能理解 Kotlin 为什么是今天的 Kotlin。对于关注语言设计的工程师，通读几份经典 KEEP 是必要的进阶功课。
