增加平台以前，先画变化会传播到哪里

一个 SDK 已支持 Linux，现在准备增加 FreeRTOS。若超时、取消和恢复都复制一遍，两端很快会出现细微差异；若把所有 OS 原语包装成相同接口，又可能隐藏通知和退出条件。边界是否合适，可以从一次具体变化的传播范围判断。

现有边界是纯 C 契约核心与独立运行时。实现见源码与版本。

以变化轴划分责任

变化	应主要影响	应保留的共同规则
新 OS/port	runtime、时间换算、创建与退出、构建	admission、身份、终态、恢复与守恒
新设备 backend	协议、能力、发送/完成与重建	接受请求后的通知义务
payload 扩大	协议与容量、复制/内存账、边界测试	不出现截断或静默接受
deadline 规则改变	core 契约、边界向量、公开文档	两端采用同一规则
新业务功能	先确认它属于哪个层次	明确输入、状态、资源和失败终态

实施以后对照实际改动范围。如果新增 OS 大量修改业务 core，先查是否混入了 OS 细节；若确实出现共同业务需求，则修改 core 并同步两端验证。

一个具体取舍：复制还是借用 payload

本例提交前复制 256-byte 控制 payload。以假设的 2000 requests/s 计算，单次复制通过的数据约为 512000 bytes/s。这个数字描述字节量，不能直接推导 CPU 耗时；还要测 cache、内存带宽和后续复制路径。

比较项	提交时复制	借用调用者 buffer
调用者复用时点	submit 返回以后	约定的完成/归还以后
接口复杂度	buffer 寿命较短	要追踪借用、取消、停止和晚到完成
内存与复制	固定内部存储，产生复制	可能减少部分副本，仍需元数据和后端存储
失败收尾	内部对象按终态回收	各种退出都要恰好归还借用
硬件约束	可集中处理内部 buffer	调用者存储也要满足 DMA/cache/对齐
本例证据	已有提交后改写原 buffer 的测试	尚无同条件收益与完整收尾实现

当前选择复制，让调用者的 buffer 寿命与异步请求分离。若后续测量显示复制成为明显成本，再引入借用方案，并先定义释放契约、故障时序与对照测试。这个决定可由新证据改变。所有权机制

给复杂度留下可观测账本

维度	记录内容	触发复查的迹象
并发	共享写者、锁序、回调上下文	同步重入或多层同时等待
寿命	持有者、借用和退出顺序	只有正常完成能回收资源
状态	转移、终态和恢复负责人	不同层同时重试、无法解释终态
配置	真正支持的 OS×设备×功能组合	“应该能跑”的组合没有回归
依赖	新平台的修改模块与反向调用	适配需要修改多个业务分支
维护	补丁传播、定位时间、分支数量	同一修复反复手工移植

没有通用的最佳数量。先记录基线，再按产品风险和维护能力限制支持组合；减少组合时也写清放弃了哪些能力。

重构分成可以回退的步骤

先保持可构建基线，把目录移动、构建调整、契约更改和行为更改分开。每一步规定回归范围和回滚条件，检查外部 consumer 能否继续只使用公开头文件。

临时平台特例记录原因、影响、责任、移除条件和验证入口。永久承诺所有旧组合会持续增加测试与修复成本，废弃计划也是架构决定的一部分。

跨平台复用用共同语义与回归约束维护。新增抽象前写清解决的实际问题、减少的变化范围，以及它引入的新寿命和配置成本。

进一步落实接口演进

兼容性与所有权演进以更大 payload、借用 buffer 与新后端为例，比较配置扩展、版本策略、归还责任和支持矩阵。