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

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

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

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

---

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

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

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

---

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

> **基线更新**：v2.0.17 已清理 `@RibbonClient` 和 `NincaCrkStdRibbonConfiguration`，Ribbon 配置完全通过 `application.properties` 控制。下文为 v2.0.16 之前的状态，保留供参考。

- 入口（当前）：[`AppApplication`](../../maven-cw-elevator-application/cw-elevator-application-starter/src/main/java/cn/cloudwalk/elevator/AppApplication.java)  
  - 无 `@RibbonClient`/`@RibbonClients` 注解。
- 入口（历史 v2.0.16 前）：`ElevatorApplication.java`  
  - 曾存在 `@RibbonClient(name = "${feign.ninca-crk-std.name:ninca-crk-std}", configuration = NincaCrkStdRibbonConfiguration.class)`
- `ninca-crk-std` 配置（历史）：`NincaCrkStdRibbonConfiguration.java`（已删除）  
  - 使用 **`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`](../../maven-cw-elevator-application/cw-elevator-application-starter/src/main/java/cn/cloudwalk/elevator/debug/ElevatorProbeConstants.java)。顺序由 Spring `@Order` / `ApplicationRunner` / `ApplicationListener` 决定：

| 组件 | 触发时机 | 顺序要点 |
|------|-----------|----------|
| [`ElevatorProbeSummaryRunner`](../../maven-cw-elevator-application/cw-elevator-application-starter/src/main/java/cn/cloudwalk/elevator/debug/ElevatorProbeSummaryRunner.java) | `ApplicationRunner` | `@Order(HIGHEST_PRECEDENCE)`：最先一批 Runner |
| [`ConfigSourceProbeRunner`](../../maven-cw-elevator-application/cw-elevator-application-starter/src/main/java/cn/cloudwalk/elevator/debug/ConfigSourceProbeRunner.java) | `ApplicationRunner` | 默认顺序；打印 **file vs classpath** 的配置源 |
| [`RibbonLoadBalancerProbeRunner`](../../maven-cw-elevator-application/cw-elevator-application-starter/src/main/java/cn/cloudwalk/elevator/debug/RibbonLoadBalancerProbeRunner.java) | `ContextRefreshedEvent` | `@Order(LOWEST_PRECEDENCE)` + **延迟** `RIBBON_LOAD_BALANCER_PROBE_DELAY_SECONDS` |
| [`ConsulUpstreamHealthProbeRunner`](../../maven-cw-elevator-application/cw-elevator-application-starter/src/main/java/cn/cloudwalk/elevator/debug/ConsulUpstreamHealthProbeRunner.java) | 同上 | **延迟** `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。

---

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