【AI-Review】【一般】【软件设计】【其他软件设计问题】API 文档与代码实现不一致：Restart 方法已从文档移除但代码仍保留

● 问题：本次变更将 Restart 方法从 API 表中删除，但实际代码中 Restart 方法仍然存在并可被调用：

• src/NativeRestart.ts 第 26 行：TurboModule Spec 接口中仍声明 Restart(reason?: string): void;
• harmony/restart/src/main/ets/RNRestartTurboModule.ts：仍实现 public Restart = this.restart;（作为 restart 的别名）

通过 src/index.tsx 的 export default RNRestart，RNRestart.Restart() 对用户仍可见可调用。

● 影响：文档与代码不一致。用户查阅 API 表时只能看到 restart 和 getReason 两个方法，但实际调用 RNRestart.Restart() 仍可正常工作。这会导致：1）用户阅读源码时发现未文档化的 API，产生困惑；2）文档无法准确反映模块对外暴露的完整接口，影响可维护性。

● 建议：二选一：

1. 若 Restart 已废弃，应在代码中同步移除 NativeRestart.ts 中的 Spec 声明和 RNRestartTurboModule.ts 中的 public Restart = this.restart; 实现；
2. 若保留 Restart 用于向后兼容，应在 API 表中保留该行并标注"已废弃，推荐使用 restart"。

【AI-Review】【一般】【软件设计】【其他软件设计问题】API 文档与代码实现不一致：Restart 方法已从文档移除但代码仍保留

● 问题：本次变更将 Restart 方法从 API 表中删除，但实际代码中 Restart 方法仍然存在并可被调用：

• src/NativeRestart.ts 第 26 行：TurboModule Spec 接口中仍声明 Restart(reason?: string): void;
• harmony/restart/src/main/ets/RNRestartTurboModule.ts：仍实现 public Restart = this.restart;（作为 restart 的别名）

通过 src/index.tsx 的 export default RNRestart，RNRestart.Restart() 对用户仍可见可调用。

● 影响：文档与代码不一致。用户查阅 API 表时只能看到 restart 和 getReason 两个方法，但实际调用 RNRestart.Restart() 仍可正常工作。这会导致：1）用户阅读源码时发现未文档化的 API，产生困惑；2）文档无法准确反映模块对外暴露的完整接口，影响可维护性。

● 建议：二选一：

1. 若 Restart 已废弃，应在代码中同步移除 NativeRestart.ts 中的 Spec 声明和 RNRestartTurboModule.ts 中的 public Restart = this.restart; 实现；
2. 若保留 Restart 用于向后兼容，应在 API 表中保留该行并标注"已废弃，推荐使用 restart"。

【AI-Review】【建议】【基础代码问题】【稳定性问题】getReason 示例缺少 Promise rejection 处理

● 问题：示例代码中 getReason 按钮的 onPress 使用 async 函数 await RNRestart.getReason()，但未添加 try-catch 错误处理。根据 harmony/restart/src/main/ets/RNRestartTurboModule.ts 中 getReason() 的实现，当静态字段 restartReason 为空（即未执行过 restart）时会执行 reject('reason is empty')，而 restartReason 初始值为空字符串 ''。

触发路径：用户首次进入 Demo（restartReason 初始为 ''）→ 直接点击 getReason 按钮（未先点击 restart）→ getReason() 执行 reject('reason is empty') → await 抛出异常 → async 函数返回 rejected Promise → 无 catch 处理 → 产生未处理的 Promise rejection。

● 影响：在用户未先点击 restart 就点击 getReason 的场景下，会产生未处理的 Promise rejection，React Native 会输出警告日志，且按钮无任何反馈（setRestartReason 和 setState 均未执行），影响示例代码的健壮性。作为 README 中的参考示例，用户可能直接复制该模式到业务代码中。

● 建议：在 onPress 中添加 try-catch 处理 rejection 场景：

onPress={async () => {
  try {
    const reason = await RNRestart.getReason();
    setRestartReason(reason);
    setState(reason);
  } catch (e) {
    setRestartReason("");
    setState("");
  }
}}

【AI-Review】【建议】【基础代码问题】【稳定性问题】getReason 示例缺少 Promise rejection 处理

● 问题：示例代码中 getReason 按钮的 onPress 使用 async 函数 await RNRestart.getReason()，但未添加 try-catch 错误处理。根据 harmony/restart/src/main/ets/RNRestartTurboModule.ts 中 getReason() 的实现，当静态字段 restartReason 为空（即未执行过 restart）时会执行 reject('reason is empty')，而 restartReason 初始值为空字符串 ''。

触发路径：用户首次进入 Demo（restartReason 初始为 ''）→ 直接点击 getReason 按钮（未先点击 restart）→ getReason() 执行 reject('reason is empty') → await 抛出异常 → async 函数返回 rejected Promise → 无 catch 处理 → 产生未处理的 Promise rejection。

● 影响：在用户未先点击 restart 就点击 getReason 的场景下，会产生未处理的 Promise rejection，React Native 会输出警告日志，且按钮无任何反馈（setRestartReason 和 setState 均未执行），影响示例代码的健壮性。作为 README 中的参考示例，用户可能直接复制该模式到业务代码中。

● 建议：在 onPress 中添加 try-catch 处理 rejection 场景：

onPress={async () => {
  try {
    const reason = await RNRestart.getReason();
    setRestartReason(reason);
    setState(reason);
  } catch (e) {
    setRestartReason("");
    setState("");
  }
}}

模板做了一些变更，后续的文档需要按照新的去更改

变更点：

1. 版本号由0.4.1更新为0.4.2
2. 顶部所属关系映射表，三方库版本修改为三方库版本（npm地址），链接修改为原先npm地址的链接，同时删除npm地址字段
3. 增加源码地址字段，值为对应分支，并添加对应分支跳转链接

另外这些也一并修改下：
1.openahrmony-sig的链接修改为CPF-RN。
2.

不再支持居中，修改为p align="center"方式居中。
3.部分库链接到usage-docs，迁移后相对路径不存在，应该使用完整路径。
例如：对于未发布到npm的旧版本，请参考安装指南安装tgz包。链接应该修改为 https://gitcode.com/CPF-RN/usage-docs/blob/master/zh-cn/tgz-usage.md
例如：> [!TIP] 如需使用直接链接源码，请参考直接链接源码说明。链接应该修改为 https://gitcode.com/CPF-RN/usage-docs/blob/master/zh-cn/link-source-code.md