一句话
论文把编程语言理论里两个老概念，效应和反效应，从「编译时检查」搬到了「运行时管理」。于是组件可以在程序运行中装上、拆下、互相依赖，既不留残渣，也不惊动别人。
这两个词听着玄，其实一句话就能分开：效应是程序对世界做了什么，反效应是世界得先给程序什么。一个管改动，一个管依赖。它们在理论界早就有，但一直只用在编译时、只管写死的代码。论文的新意，是让它们管住运行中来来去去的组件。
一页摘要，两页目录。
和效应系统、动态更新、组件框架等已有研究的比较。
六十多条参考文献。
五项贡献，对应本书五章
| 论文的贡献 | 一句话 | 本书 |
|---|---|---|
| 可逆效应 | 每个改动当场附带撤销办法，由运行时保管 | 04 回执 |
| 响应式反效应 | 依赖写成清单，环境一变就对照，自动上岗或歇业 | 05 插座 |
| 语境范式 | 所有改动和依赖都走同一本总账，由此互不干扰 | 06 一扇门 |
| 动态组装演算 | 把前三样合成「组件」，证明整个系统一起跑也成立 | 07 一生 |
| Cordis | 把这套理论写成能用的框架，并在 Koishi 上验证 | 08 落地 |
三句口诀
- 01每个改动，当场交出撤销办法。时间 · 拆得干净 →
- 02每个组件，进门先交需求清单。空间 · 接得稳 →
- 03所有事情，都走同一扇门。把前两句拧在一起 →
插上，就是执行；拔下，就是撤销
论文第 22 页有一句很朴素的话：装上一个组件，等于执行它的效应，好比插上插头；卸下一个组件，等于撤销它的效应，好比拔下插头，而且不影响其他还在跑的组件 p.22。
本书的两个比喻就从这里来：时间这道题，想成「回执」；空间这道题，想成「插座」。
五张字据：它到底证明了什么
论文用了 26 页公式，证明一整个系统在任意装卸之下仍然成立。结论是五条性质，按原文第 4.3 节的顺序：
| 性质 | 意思 | 详见 |
|---|---|---|
| 保持 | 不管怎么装卸，系统每一步都处在合法状态，账始终对得上 | 07 |
| 时间可组装 | 拆掉一个组件，环境回到它来之前的样子 | 04 |
| 空间可组装 | 组件只在依赖齐全时上岗；只有给它供货的那一位真换了人，它才重新上岗 | 05 |
| 进展 | 系统不会卡死在半路，「等别人先走」的护栏总会放行 p.37 | 07 |
| 汇聚 | 中间怎么折腾都不留痕迹，结局只看最终配置 p.51 | 07 |
证据，和它自己承认的缺口
证据来自 Koishi：四年多、4000 多个社区插件 p.69。控制台里停用一个插件，它的改动当场撤回；开发时改了代码一保存，插件原地重载，其余部分的缓存和连接都还在。Koishi 的网页控制台本身又是另一个独立的 Cordis 应用，跑在浏览器里，说明这套模型不挑运行环境。
缺口论文自己写得很清楚 p.70：只在一个生态、一种语言（TypeScript）上验证过；是观察，不是和其他架构的对照实验；开销有多大、对开发效率有多大帮助，都还没量化。另外两条，后面会反复出现：撤销函数写得对不对，框架不检查，靠作者 p.59；已经发出去的消息、写出去的文件，撤不回来，只能补偿 p.71。
还有个版本细节，论文自己注明了：Koishi 跑的是上一代 Cordis（文中称 v3），论文讲的是新一代 v4，两代的核心组合模型相同 p.69。
效应管时间，反效应管空间，语境把两者拧成一股；组件只是三者的合体。
我在读论文 A Programming Paradigm for Spatiotemporal Composability（arXiv:2608.25512，Cordis 框架）。 请用我的项目举例，分别说明： 1. 我的项目里哪些操作算「效应」（对外部做的改动），它们现在有没有对应的撤销办法； 2. 哪些模块之间有「反效应」（依赖），现在是怎么声明的； 3. 有没有绕开统一入口、直接改全局状态的地方。