starRiverProperty/docs/testing/elevator-v1-v2-init-timing-config-audit.md

电梯 V1 / V2：初始化时序与配置审核备忘（不改现场属性文件）

约束：本文档仅做代码与模板对照、启动与探针时序说明；不修改现场 bootstrap.properties / application.properties。

关联：证据与日志结论见 elevator-evidence-v1-v2-diff-20260430.md；Ribbon 现象见 elevator-service-instance-missing-investigation.md。

---

1. 仓库内「V1 模板」与「V2 模板」指代

指代	路径	用途
V1 部署参考	deploy/v1-legacy/application.properties	同目录 fat-jar、Consul 发现关闭场景下的 显式 ninca-crk-std.ribbon.listOfServers 示例
V2 部署参考	deploy/v2-maven/application.properties、bootstrap.properties	当前 Maven 发布包拷贝来源；含 ninca-crk-std.ip，默认不含 ninca-crk-std.ribbon.listOfServers（与 V1 示例段不同）

现场实际生效属性以磁盘文件 + Consul KV + 内嵌 classpath 合并为准；证据包中探针已打印多源并存现象。

---

2. 应用入口与 Ribbon 绑定（代码层，与属性文件无关）

• 入口：ElevatorApplication
  • @RibbonClient(name = "${feign.ninca-crk-std.name:ninca-crk-std}", configuration = NincaCrkStdRibbonConfiguration.class)
• ninca-crk-std 专用配置：NincaCrkStdRibbonConfiguration
  • 使用 ConfigurationBasedServerList，initWithNiwsConfig 从 Ribbon 约定键（如 ninca-crk-std.ribbon.listOfServers）取列表。
  • 业务键 ninca-crk-std.ip（如 AcsElevatorRecordServiceImpl）不自动写入 Ribbon ServerList；二者语义分离。

审核结论：在未改属性文件的前提下，若需证明「仅 ip、无 listOfServers」与空列表的因果关系，应依赖日志中的 ServerList 初始化行 + ConfigSourceProbe 已打印的 ninca-crk-std.ribbon.listOfServers value=null（证据包已包含）。

---

3. 探针与启动时序（已实现的审查手段）

以下组件默认均启用（无 elevator.*.probe 开关）；延迟秒数见 ElevatorProbeConstants。顺序由 Spring @Order / ApplicationRunner / ApplicationListener 决定：

组件	触发时机	顺序要点
ElevatorProbeSummaryRunner	ApplicationRunner	@Order(HIGHEST_PRECEDENCE)：最先一批 Runner
ConfigSourceProbeRunner	ApplicationRunner	默认顺序；打印 file vs classpath 的配置源
RibbonLoadBalancerProbeRunner	ContextRefreshedEvent	@Order(LOWEST_PRECEDENCE) + 延迟 RIBBON_LOAD_BALANCER_PROBE_DELAY_SECONDS
ConsulUpstreamHealthProbeRunner	同上	延迟 CONSUL_HTTP_PROBE_DELAY_SECONDS（先于 Ribbon 数秒，减少日志交错）

审核结论：ConfigSource 探针回答「合并后的 Environment 里键值与来源」；Ribbon/Consul 探针回答「延迟若干秒后负载均衡与 Consul HTTP 是否一致」。与「首次请求才创建 LoadBalancer」的懒加载配合时，日志时间戳比单次启动瞬间的配置快照更能说明时序问题（见全量 elevator-app.log 中 11:16 vs 11:43 两次启动）。

---

4. jcmd attach 失败时的排查动作（不改属性）

采集脚本已输出 jcmd-attach-diagnose.txt（进程用户、/tmp/hsperfdata_*、cmdline 中与 attach 相关的 token）。常见修复：

1. 与 Java 进程同一用户执行 jcmd（例如进程属 cwos 而当前为 root 时：sudo -u cwos /data/cwos/java/bin/jcmd <PID> VM.system_properties）。
2. 检查 /tmp/hsperfdata_<user>/<pid> 是否存在、权限是否正常。
3. 确认启动参数中是否包含 -XX:+DisableAttachMechanism（若有则需调整 启动脚本/JVM 参数，不属于应用 properties）。
4. JDWP（-Xdebug / -Xrunjdwp）一般不单独阻断 attach；仍以用户与 hsperfdata 为主因居多。

---

5. 下一步「仅从审核角度」的建议清单（不写回属性文件）

1. 对照本次证据包与全量日志：确认 ninca-crk-std 首次出现 ConfigurationBasedServerList + Servers=[] 的线程与时间，是否与首次 Feign 调用/懒加载一致。
2. 对照 V1 legacy 模板与 v2-maven 模板中 ninca-crk-std.ribbon.* 段的差异，形成变更评审材料（实施与否由现场窗口决定，本文不修改文件）。
3. 复采证据时带上 jcmd-attach-diagnose.txt 与成功时的 jcmd-system-properties.txt，补齐进程内 ribbon.* 最终值。
4. 短时开启 Ribbon / Consul 探针（仅运行时开关，不改磁盘 properties 内容亦可由运维在启动命令注入 -D）用于一次性对照——若政策禁止任何参数变更，则仅依赖现有日志与 Consul JSON。

---

文档性质：研发侧审核备忘；不作为未经评审的生产变更指令。