只读属性本身不能测量实例化耗时，需在初始化逻辑中嵌入时间戳并写入只读字段（如_initDurationMs），再通过审计服务聚合分析；其本质是可信状态快照，不参与执行过程，但可作为耗时审计的最终锚点。

直接利用只读属性本身无法测量实例化耗时——它只限制修改，不提供计时能力。真正可行的路径是：在组件初始化逻辑中嵌入轻量级时间戳采集，并将结果写入只读字段（如自定义元数据或日志属性），再通过统一审计服务批量读取、聚合分析。

明确只读属性的定位与边界

只读属性（如 Project 中的“计划工期”“受保护的实际加班工时”，或阅读器 SDK 中的 nodeType、dataId）本质是状态快照或计算结果的最终呈现，不可写入但可安全读取。它不参与执行过程，也不触发钩子。因此：

• 不能靠监听只读字段变化来捕获实例化时刻
• 不能在只读字段上直接注入计时逻辑
• 它的价值在于作为可信锚点——一旦写入，即代表该次实例化已完成且结果已固化

在初始化链路中埋点并落库到只读字段

以 Reader Kit 的 PhonePC/2in1Tablet 构造函数为例，可在其实现中加入毫秒级时间戳采集：

• 在构造函数入口记录 start = performance.now()
• 在构造完成、关键属性（如 dataId）生成后，计算耗时：duration = performance.now() - start
• 将 duration 作为只读元数据附加到实例（例如挂载为 this._initDurationMs，设为 getter-only 属性）
• 若框架支持，也可将该耗时写入统一监控日志或上报至审计服务端，同时确保日志条目本身带不可篡改时间戳和 traceID

构建自动化审计流水线

只读属性的价值在规模化读取时才真正释放。建议搭建三层轻量审计机制：

• 采集层：通过项目构建插件或运行时代理（如 WebView2 的 DevTools 协议监听），自动识别所有继承自 ReaderCoreIdentity 的组件实例，并提取其 _initDurationMs 或等效只读耗时字段
• 聚合层：按组件类型（nodeType）、设备形态（PhonePC / 2in1Tablet）、页面加载阶段（首屏/懒加载）分组统计 P50/P90 耗时、异常值（>300ms）占比
• 告警层：当某类微任务连续 3 次 P90 超过阈值，或单次耗时突破 1s，自动触发 PR 检查注释或飞书告警，附带调用栈快照与前后资源加载水位

规避常见陷阱

实践中容易忽略的关键细节：

• 避免在构造函数中执行 DOM 操作或网络请求——这会污染耗时数据，应移至 onReady 等生命周期钩子
• 注意多线程环境（如 WebView2 多进程）下 performance.now() 的时钟一致性，优先使用同一进程内采集
• 只读字段若由服务端下发（如预渲染 dataId），需确认耗时是否包含网络 RTT；建议客户端侧单独测纯构造耗时，服务端侧另做 SSR 渲染耗时审计
• 不要把“只读”误解为“不可观测”——它恰恰是审计信任链的终点：你信任它，是因为它不可被运行时逻辑随意覆盖