应通过微观压测验证编译期自动织入逻辑的行为一致性，倒逼形成四条硬性编码规范：禁止修改输入参数、明确线程安全策略、异常须包装为运行时异常并保留cause、每个织入点配最小单元测试；压测脚本需纳入CI门禁，失败时精准关联规范条款。
这个问题其实是在问：如何用微观压测手段，验证编译期自动织入逻辑（比如 c# 13 拦截器、java agent 字节码增强、或类似 aop 的静态注入）在真实运行时的底层行为，并据此反向提炼出团队必须遵守的核心编码规范。
先搞清“自动关闭编译后隐式织入”的真实含义
所谓“自动关闭”，不是指功能开关，而是指这类机制默认不生效、需显式启用（如加 [InterceptsLocation] 或配置插件），且一旦启用，逻辑就固化在编译产物中，运行时不可动态卸载或绕过。“隐式织入”意味着业务代码里看不到调用痕迹——你写的是 ReadHoldingRegisters()，实际执行的却是带 CRC 校验和熔断的增强版本。这种“看不见的逻辑”恰恰是规范最该约束的地方。
微观压测不是测性能，而是测行为一致性
重点不是看 QPS 提高多少，而是验证三件事是否始终成立：
- 织入点精准性：拦截是否只发生在标注位置？有没有因泛型擦除、重载解析错误或多态分发导致漏织或误织？
- 状态隔离性：多个线程/协程并发调用同一织入方法时，共享变量（如缓存、计数器）是否被意外污染？有没有隐式依赖静态上下文？
- 异常传播完整性：织入逻辑抛出异常时，原始堆栈是否被截断？能否准确定位到业务代码行号，而非拦截器内部？
用压测结果倒逼四条硬性规范
基于多次微观压测暴露的问题，可明确写入团队规范：
-
禁止在织入逻辑中修改业务方法的输入参数值（如直接改
ref参数或集合内容），否则会导致业务侧感知不一致；应仅做校验、记录或返回新对象。 -
所有织入逻辑必须声明明确的线程安全策略：若用静态缓存，必须加锁或用
ConcurrentDictionary；若无状态，则标注[ThreadSafe]注解供扫描工具识别。 - 织入方法不得抛出受检异常（Java）或未声明异常（C#），否则会破坏原始方法签名契约；异常必须包装为运行时异常并保留原始 cause。
- 每个织入点必须配套一份最小可验证单元测试，测试用例需覆盖：正常流程、边界输入、异常路径、多线程并发——且测试代码本身不能依赖任何框架，只调用编译后的 IL 或字节码。
把压测能力变成规范落地的基础设施
将微观压测脚本封装成 CI 阶段的必过门禁：
- 在 PR 合并前，自动对新增/修改的织入逻辑运行 5 秒 1000 并发压测；
- 失败时不仅报“超时”或“OOM”，而是输出具体问题类型（如“堆栈丢失”“静态变量竞争”“非预期重入”）；
- 报告直接关联到规范条款编号，例如：“违反规范 #3.2 —— 织入逻辑抛出未声明异常”。
