【AI-Review】【一般】【基础代码问题】【代码逻辑错误】英文 README 的 Autolink 指南链接指向中文文档

● 问题：README_en.md 第43行将 Autolink 框架指南链接指向 https://gitcode.com/CPF-RN/ohos_react_native/blob/master/docs/zh-cn/Autolinking.md，该 URL 路径包含 zh-cn，是中文版文档。README_en.md 是面向英文用户的文档，英文用户点击该链接后会进入中文页面，无法理解内容。通过 GitCode API 验证（GET /api/v5/repos/CPF-RN/ohos_react_native/contents/docs/en?ref=master），ohos_react_native 仓库的 docs/en/ 目录下不存在 Autolinking.md 文件，该目录仅有 Codegen.md、TurboModule.md、architecture.md 等文件，即 Autolink 指南目前仅有中文版，没有对应的英文翻译。

● 影响：一般。英文用户按照文档操作时，点击 Autolink 指南链接会进入中文页面，无法获取英文操作指导，影响文档可用性。

● 建议：在链接后补充说明该指南目前仅提供中文版，例如："AutoLink framework guide (currently available in Chinese only): https://gitcode.com/CPF-RN/ohos_react_native/blob/master/docs/zh-cn/Autolinking.md"，待英文版翻译完成后更新为 docs/en/Autolinking.md 链接。

【AI-Review】【一般】【基础代码问题】【可读性问题】英文版 README 链接到中文版 Autolinking 文档

● 问题: 第43行 AutoLink 框架指导文档的链接指向 docs/zh-cn/Autolinking.md（中文版），但当前文件是英文 README（README_en.md）。英文版文档中的链接应指向英文版 Autolinking 文档。经验证，英文版 Autolinking 文档存在于 https://gitcode.com/CPF-RN/ohos_react_native/blob/master/docs/en/Autolinking.md（HTTP 200）。

触发路径：英文用户阅读 README_en.md → 点击第43行 "AutoLink framework guide" 链接 → 跳转到中文版 Autolinking.md（docs/zh-cn/Autolinking.md）→ 用户无法阅读中文文档，无法获取 Autolink 配置指导。

对比：同文件第145行的 "Directly Linking Source Code" 链接正确指向了英文版 usage-docs/blob/master/en/link-source-code.md，说明项目存在英文版文档惯例（/en/ 路径），第43行未遵循此惯例。

● 影响: 一般。英文用户无法正常使用 Autolink 配置文档，影响接入体验。

● 建议: 将第43行链接中的 zh-cn 改为 en： Projects using AutoLink need to be configured according to this document, AutoLink framework guide: https://gitcode.com/CPF-RN/ohos_react_native/blob/master/docs/en/Autolinking.md

【AI-Review】【一般】【基础代码问题】【代码逻辑错误】兼容性验证版本与依赖声明不一致

● 问题：README_en.md 第241行声明 "RNOH: 0.72.33" 为文档验证通过的版本。但 harmony/background_timer/oh-package.json5 第9行声明依赖 @rnoh/react-native-openharmony: ^0.72.38，根目录 package.json 第43行也声明 react-native-harmony: npm:@react-native-oh/react-native-harmony@^0.72.38。semver 范围 ^0.72.38 要求版本 >=0.72.38 且 <0.73.0，而 0.72.33 < 0.72.38，不满足该范围。

● 影响：一般。用户根据 README 兼容性说明，在工程中使用 RNOH 0.72.33 版本，执行 ohpm install 安装本库时，ohpm 会因 @rnoh/react-native-openharmony 版本不满足 ^0.72.38 而报依赖冲突错误，导致安装失败。文档声明的验证版本与实际依赖要求不一致，会误导用户。

● 建议：将第2条验证版本中的 RNOH 版本更新为满足 ^0.72.38 要求的版本（>=0.72.38），或者如果确实需要在低版本上验证，则需同步下调 oh-package.json5 和 package.json 中的最低依赖版本。推荐保持依赖声明不变，更新 README 中的验证版本为实际验证过的 >=0.72.38 版本。

【AI-Review】【严重】【基础代码问题】【代码逻辑错误】示例代码 timeoutList 未持久化导致 clearTimeout 失效

● 问题：README_en.md 第263行将 timeoutList 声明为函数组件体内的普通局部变量 let timeoutList:number[] = []，而非使用 useState 或 useRef。在 React 函数组件中，每次 re-render 都会重新执行函数体并创建一个新的空数组。执行路径如下：用户点击 "setTimeout" 按钮 → setTimeoutStart（第279行）执行，将 timeoutId push 到当前渲染的 timeoutList → 随后 setText("Turn on the timer...")（第280行）触发 re-render → 新渲染产生新的空 timeoutList，原数组（含已 push 的 timeoutId）丢失 → 用户点击 "clearTimeout" 按钮 → setTimeoutStop（第286行）读取的是新渲染产生的空 timeoutList → timeoutList.length>0（第288行）为 false → BackgroundTimer.clearTimeout（第289行）永远不会被执行。同文件第264行对功能等价的 intervalList 正确使用了 useState，可佐证 timeoutList 的写法与设计意图不一致。

● 影响：严重。用户复制该示例代码运行后，"clearTimeout" 按钮点击后定时器不会被清除，后台仍持续触发回调。这与示例预期行为不符，会让用户误以为 BackgroundTimer.clearTimeout 接口无效。

● 建议：将 timeoutList 改为 useState 持久化存储，与 intervalList 保持一致：

let [timeoutList, setTimeoutList] = useState<number[]>([]);
// In setTimeoutStart:
setTimeoutList(prev => [...prev, timeoutId]);
// In setTimeoutStop:
if (timeoutList.length > 0) {
  BackgroundTimer.clearTimeout(timeoutList[0]);
  setTimeoutList(prev => prev.slice(1));
}

【AI-Review】【一般】【基础代码问题】【代码逻辑错误】setCount(count+=1) 直接修改 state 变量导致定时器运行中 Reset 后计数跳变

● 问题：README_en.md 第270行 runBackgroundTimer 的回调中使用 setCount(count+=1) 直接修改 state 变量 count。该回调在 onPressStart（第267行）调用时创建，闭包捕获的是当时 render 的 count 变量。由于 runBackgroundTimer 会持续按 delay 间隔触发该回调，每次触发执行 count+=1 都在修改闭包中的 count 变量，而该变量与 React 内部 state 是两份独立的数据。当用户在定时器运行期间点击 "Reset" 按钮（第309-312行 resetNumber 调用 setCount(0)），React state 被重置为 0，但定时器回调仍闭包引用旧的 count 变量（此时已被多次自增到较大值，如 5）。下一次定时器触发时：count+=1 将闭包中的 count 从 5 变为 6，setCount(6) 使显示值从 0 直接跳到 6，而非从 0 重新开始。同样的 setCount(count+=1) 写法也出现在第298行 setInterval 回调中，存在相同问题。

● 影响：一般。用户在定时器运行期间点击 Reset 后，计数器不会从 0 重新开始递增，而是跳变到定时器闭包中累积的旧值+1，与用户预期不符，示例代码行为不正确。

● 建议：使用函数式更新获取最新 state，避免直接修改 state 变量： BackgroundTimer.runBackgroundTimer(() => { setCount(prev => prev + 1) }, parseInt(delay)) 第298行 setInterval 回调也应同样修改为 setCount(prev => prev + 1)。

【AI-Review】【一般】【基础代码问题】【代码逻辑错误】intervalList.shift() mutates React state without setState update

● 问题: Line 306 in setIntervalStop() calls intervalList.shift() which directly mutates the state array managed by useState without calling setIntervalList. intervalList is declared at line 264 via let [intervalList, setIntervalList] = useState<number[]>([]), making it React state that must be updated immutably. Array.prototype.shift() mutates the array reference in place and bypasses React's state update mechanism.

Trigger path: User clicks "setInterval" button → setIntervalStart() calls setIntervalList([...intervalList, intervalId]) correctly updating state immutably → UI shows the new interval. User clicks "clearInterval" button → setIntervalStop() executes: line 303 setText("Turn off the timer") triggers re-render → line 305 BackgroundTimer.clearInterval(intervalList[0]) clears the timer → line 306 intervalList.shift() mutates the state array in place without calling setIntervalList → React cannot detect the intervalList state change. Although setText triggers a re-render, the state update for intervalList is unreliable because it bypasses the setState channel, leading to UI-state desynchronization in subsequent operations (clicking setInterval/clearInterval again) or concurrent update scenarios.

● 影响: General. Directly mutating state is a React anti-pattern that can cause UI-state desynchronization: after clicking clearInterval, the UI may still show the cleared interval; subsequent setIntervalList calls may compute new values based on the in-place mutated old reference, causing list data corruption.

● 建议: Use setIntervalList to update immutably, replacing intervalList.shift(): setIntervalList(prev => prev.slice(1)); This allows React to properly detect the state change and trigger re-render.