@react-native-ohos/native-stack 只在 OHOS 平台存在，但 peerDependencies 里没有对应 peerDependenciesMeta.optional 标记。非 OHOS 平台安装时 npm/yarn 会报 unmet peer dependency 警告。参照上面 react-native-windows 的做法，给它也加一个 optional: true？

peerDependencies 里 @react-native-ohos/native-stack 下限是 7.4.0-rc.12，是个 RC 版本。消费方 npm install 可能拉到不稳定的预发布版，是否等稳定版发布后再合入，或者至少把下限收到 >=7.4.0？

waitRedrawEnd 用 requestAnimationFrame 轮询累计 100ms 来等 native 全屏重绘完成，但 rAF 只保证 JS 帧回调，不等 native 侧真正画完。低端设备或高负载时 100ms 可能不够，高端设备上又白等。native-stack 有没有提供 fullscreen 切换完成的回调或 Promise？有的话用它比硬等靠谱。

waitRedrawEnd 用 requestAnimationFrame 循环轮询 Date.now() 直到过 100ms，但从未检查 redraw 是否真的完成——实质上就是 setTimeout(100)，还多了 rAF 的调度开销。如果目的是等 native 全屏生效后再锁方向，有没有 native 侧的回调或事件可以用？如果没有，至少直接用 setTimeout 更直观。

100ms 硬编码等帧绘制完成——慢设备可能不够、快设备白等。setIsFullScreen 有没有回调或返回 promise 能知道全屏切换真正完成了？用 rAF 轮询 100ms 不太靠谱，而且 unlock 路径里也没有 setIsFullScreen(false)，从横屏解锁后全屏状态会残留。

lockToLandscapeLeft、lockToLandscapeRight、lockToPortraitUpsideDown 都没有调 setIsFullScreen，只有 lockToLandscape 和 lockToPortrait 改了。如果业务直接调 lockToLandscapeLeft，全屏状态和实际方向会不一致。是不是该把 setIsFullScreen 收到一个内部统一入口，或者每个 lock 方法都补上？

lockToLandscapeLeft 和 lockToLandscapeRight 没有调用 setIsFullScreen(true)，如果业务侧走这两个方法锁横屏，全屏不会开启，画面会裁在 non-fullscreen 区域里。三个横屏入口是不是都要加？

只有 lockToLandscape 加了 setIsFullScreen(true) + waitRedrawEnd，lockToLandscapeLeft 和 lockToLandscapeRight 没改。通过这两个入口进横屏时全屏不会开启，是有意为之还是漏了？

快速连续调 lockToLandscape 会创建多个 pending promise，每个到期后都会再调一次 OrientationNative.lockToLandscape()。加个 generation 计数器或取消前一个 pending，避免过期回调覆盖新状态。

lockToLandscape 把 native 调用延迟到 waitRedrawEnd 之后，但 locked 在延迟之前就置 true 了。如果这 100ms+ 的窗口里用户又调了 lockToPortrait，portrait 的 native 调用会立即执行，然后被随后触发的 deferred landscape 覆盖——最终停在横屏，和最后一次调用意图相反。可以考虑用一个 pending 队列或者 cancel 上一次 deferred 的方式，保证只有最后一次 lock 调用真正落到 native。