Changelog Local - 学习记录与技术积累

目录

1. bundle exec pod install vs pod install 的区别
2. Xcode 多版本管理：安装、切换与 macOS 兼容性
3. GitLab Personal Access Token 与 postinstall 脚本机制
4. Git 认证（SSH/HTTPS）vs GitLab API Token 的区别
5. Xcode 26 适配 RN 0.66 项目：7 个编译补丁全记录
6. Hybrid App 架构：Native + RN 混合开发模式
7. JS 引擎与 JS Bundle：RN 代码如何在手机上运行
8. MQTT 协议：为什么打印系统不用 HTTP/WebSocket
9. RN 性能优化：为什么不分包 + 首屏优化手段全景
10. Node.js 版本与 OpenSSL 兼容性：ERR_OSSL_EVP_UNSUPPORTED 排查
11. Native Bridge 双向通信机制
12. Service 单例 + Provider 模式：轻量级状态管理
13. 业务插件系统与模块化架构
14. 企业级打印系统：蓝牙 + MQTT 双通道架构

1. bundle exec pod install vs pod install 的区别

一句话结论

bundle exec pod install 使用项目 Gemfile 锁定版本的 CocoaPods，确保团队所有人用同一版本；直接 pod install 用的是系统全局版本，每台电脑可能不同。

为什么需要了解这个

在 iOS + React Native 项目中，pod install 是安装原生依赖的关键步骤。如果团队成员用不同版本的 CocoaPods，会导致 Podfile.lock 产生 diff，甚至出现"我这里能跑你那里不行"的问题。理解这个机制是理解 iOS 工程化的基础。

原理 / 本质

CocoaPods 本身是一个 Ruby gem（类似于 npm 包）。Ruby 生态用 Bundler 来管理 gem 的版本，就像前端用 yarn/npm 管理 node_modules。

直接 pod install 的执行路径：

pod install
    │
    ▼
系统全局的 CocoaPods（可能是 1.11、1.14、1.16… 每台电脑不同）
    │
    ▼
生成的 Podfile.lock 取决于你碰巧装了哪个版本

bundle exec pod install 的执行路径：

bundle install          ← 根据 Gemfile + Gemfile.lock 安装指定版本的 gem
    │
    ▼
bundle exec pod install ← 用 Bundler 管理的那个特定版本的 pod 来执行
    │
    ▼
Gemfile.lock 里锁定的 CocoaPods（比如精确到 1.14.3，所有人一致）

与前端已知知识的类比

关键类比：你不会在项目里用全局的 webpack 版本去构建，而是用 npx webpack 或 yarn build 调用项目本地的版本。同理，bundle exec 就是 Ruby 世界的 npx。

三层对比

❌ 初级做法：直接 pod install
   → 用全局版本，和同事版本不一致时 Podfile.lock 反复冲突，
     甚至编译失败但不知道为什么

⚠️ 中级做法：知道用 bundle exec pod install，但不理解为什么
   → 能跑通，但 Gemfile.lock 冲突时不知道怎么处理

✅ 资深做法：理解 Bundler 机制，知道 Gemfile.lock 锁定了什么
   → 能解释为什么要锁版本、出了 lock 文件冲突知道怎么解决
   → 知道 CI 环境也必须用 bundle exec 保持一致
   → 知道什么时候该 bundle update 升级 CocoaPods 版本

本项目中的体现

项目已经配置了 Gemfile：

• ios/Gemfile — 声明依赖的 gem 及版本范围
• ios/Gemfile.lock — 锁定精确版本

说明团队有意锁定 CocoaPods 版本，所以应该始终使用：

cd ios
bundle install           # 第一次或 Gemfile 改了才需要
bundle exec pod install  # 之后每次都用这个

面试 / 技术对话角度

面试官可能怎么问：

• 初级追问："pod install 和 pod update 有什么区别？"
• 资深追问："你们团队怎么保证 iOS 依赖版本一致性的？CI 里怎么处理？"

面试话术："我们团队用 Bundler 锁定 CocoaPods 版本，通过 Gemfile.lock 确保所有开发者和 CI 用同一版本的 CocoaPods 执行 pod install。这和前端用 yarn.lock 锁定依赖版本是同一个思路——核心目标是构建可复现性。之前有同事直接用全局 pod install 导致 Podfile.lock 反复冲突，统一用 bundle exec 后就彻底解决了。"

延伸讨论

Q: pod install 和 pod update 有什么区别？

• pod install：按 Podfile.lock 安装已锁定的版本，新增的 pod 才会去解析最新版本
• pod update：忽略 Podfile.lock，重新解析所有 pod 的最新版本并更新 lock 文件
• 类比：yarn install（尊重 lock）vs 删掉 yarn.lock 再 yarn install（全部重新解析）

Q: Gemfile.lock 冲突了怎么办？

• 选择一方的版本，然后重新 bundle exec pod install 让 Podfile.lock 重新生成
• 关键是保证 Gemfile.lock 里的 CocoaPods 版本是团队约定的版本

思考题讨论

Q1：为什么不能直接 rm Gemfile.lock && bundle install 重新生成？

用户回答：不清楚锁文件的"供应链契约"属性。

暴露的知识盲区：把 lock 文件当作"缓存"而不是"契约"——不理解 lock 文件保证的是构建可复现性，而不是"性能优化"。

正确解答：

Gemfile 只声明了版本范围（如 cocoapods ~> 1.14 意思是 1.14.x），而 lock 文件锁定的是精确版本。删掉 lock 后重新 install：

Gemfile 声明:  cocoapods ~> 1.14
             │
             ├─ 第一次 install  → 拿到 1.14.3 → 写入 Gemfile.lock
             │
             ├─ 删掉 lock，两周后 install  → 拿到 1.14.5（1.14.x 最新）
             │                              → 构建产物可能不同
             │
             └─ 更糟：传递依赖升级
                cocoapods 1.14.3 依赖 xcodeproj ~> 1.21
                可能解析到 1.21.0 或 1.24.0，行为有差异

本质：lock 文件是**"所有人用同一版本"的契约**，不是"加速安装"的缓存。删掉=主动撕毁契约。

类比前端：package-lock.json 同理。有些人用 rm package-lock.json 解冲突，结果 npm install 解析出的次要依赖版本飘了，生产环境 bug 复现不出来——这就是放弃可复现性的代价。

Q2：bundle install 和 bundle update 什么时候用哪个？

用户回答：不清楚两个命令的语义差异。

正确解答：

bundle install：
  - 有 Gemfile.lock → 按 lock 装精确版本（尊重契约）
  - 没 lock → 按 Gemfile 解析最新 → 写入 lock
  - 对应 npm: npm ci（严格）

bundle update：
  - 忽略 lock，按 Gemfile 版本范围解析最新 → 重写 lock
  - 对应 npm: rm package-lock.json && npm install

bundle update <gem>：
  - 只升级指定 gem，其他保持 lock 里的版本
  - 精确控制升级范围，不会意外升级其他依赖

何时用 update：

• 主动升级某个 gem 修 CVE 漏洞 → bundle update cocoapods
• 不要日常 bundle update 全量升级——会批量引入未测试的新版本

面试话术："Bundler 的 install 和 update 语义完全不同，对应的是 npm ci 和 npm update。日常开发必须用 install 保证所有人用同一版本；只有明确要升级某个 gem 时才用 update，并且通常指定单个 gem 避免批量升级引入风险。这和我做前端时对待 package-lock 的态度完全一致——lock 文件是契约，不是性能优化。"

安全思维：Gemfile.lock 的供应链风险

一个 lock 文件能锁版本号，但锁不住源码篡改：

攻击场景：
  Gemfile.lock 锁定 cocoapods 1.14.3
  攻击者如果劫持了 rubygems.org 或做中间人攻击
  ↓
  下发的 1.14.3 其实是植入恶意代码的版本
  但 lock 文件看不出来——只比对版本号

真正的防御：

1. 校验和锁定：Bundler 2.2+ 的 --add-checksums 可以在 lock 中写入 gem 的 SHA 校验和
2. 私有源：企业级项目用自建的 Gem 镜像（类似 npm 的 Verdaccio），不直接从公网拉
3. 审计：bundle audit 检查已知漏洞的 gem 版本

这和 npm 的 package-lock.json + npm audit + 私有 registry 是完全一样的防御思路。

2. Xcode 多版本管理：安装、切换与 macOS 兼容性

一句话结论

Xcode 支持多版本并存，通过 xcode-select 或第三方工具 xcodes 切换，但要注意 macOS 版本和 Xcode 版本之间存在硬性兼容约束。

为什么需要了解这个

不同项目依赖不同 Xcode 版本。老项目（如 RN 0.66）用新 Xcode 可能编译不过，新项目需要新 Xcode 支持最新 iOS SDK。作为同时维护多个项目的开发者，多版本管理是必备技能。

原理 / 本质

Xcode 每个版本就是一个独立的 .app 文件，可以同时装多个放在 /Applications 下：

/Applications/Xcode.app            ← 默认版本（比如 Xcode 26）
/Applications/Xcode-14.3.1.app     ← 老版本
/Applications/Xcode-15.4.0.app     ← 另一个版本

系统通过 xcode-select 这个命令行工具来决定当前激活哪个 Xcode，它本质上是修改一个全局指针，指向某个 Xcode 的 Developer 目录。所有依赖 Xcode 工具链的操作（编译、模拟器、xcodebuild）都会跟着这个指针走。

与前端已知知识的类比

关键类比：xcode-select 就是 Xcode 世界的 nvm use，xcodes 就是 Xcode 世界的 nvm。

常用命令速查

# ====== 安装 xcodes（Xcode 版本管理工具）======
brew install xcodes

# ====== 查看 / 安装 / 切换 ======
xcodes list                  # 列出所有可用版本（类似 nvm ls-remote）
xcodes installed             # 列出已安装版本（类似 nvm ls）
xcodes install 14.3.1        # 安装指定版本（需要 Apple ID 登录）
sudo xcodes select 14.3.1    # 切换到指定版本（类似 nvm use）

# ====== 原生命令（不用 xcodes 也能切换）======
xcodebuild -version                         # 查看当前版本
xcode-select -p                             # 查看当前激活的 Xcode 路径
sudo xcode-select -s /Applications/Xcode-14.3.1.app/Contents/Developer  # 切换

macOS 与 Xcode 版本兼容性（硬限制）

这是一个双向约束：

• 新 Xcode 要求新 macOS：Xcode 16 要求 macOS 14+，装不上 macOS 13
• 新 macOS 可能跑不了老 Xcode：macOS 15 上 Xcode 14 可能打不开或工具链异常

常见对应关系：

实际影响：如果你的 macOS 是 15 (Sequoia)，基本只能可靠运行 Xcode 15 和 16（以及更新的版本）。老项目在新 Xcode 上编译报错，通常通过打补丁解决，而不是降级 Xcode。

三层对比

❌ 初级做法：只装一个 Xcode，新项目老项目都用同一个版本
   → 老项目编译失败就束手无策，或者升级 Xcode 导致新项目又出问题

⚠️ 中级做法：知道可以装多版本，但不理解兼容性约束
   → 花很长时间下载安装了一个老版本 Xcode，结果发现 macOS 不支持

✅ 资深做法：了解版本兼容矩阵，优先在当前 Xcode 上修编译问题
   → 知道降 Xcode 不如打补丁（社区有大量 RN + 新 Xcode 的修复方案）
   → CI 上也配置了明确的 Xcode 版本，保证构建可复现
   → 用 xcodes 管理多版本，切换高效

本项目中的体现

通过 ios/slh_new.xcodeproj/project.pbxproj 分析：

• objectVersion = 54 → Xcode 14 引入的项目格式
• IPHONEOS_DEPLOYMENT_TARGET = 13.0 → 最低支持 iOS 13
• React Native 0.66.4 → 2021 年底的版本，官方适配的是 Xcode 14 系列

当前开发机 macOS 为 Sequoia (15)，安装了 Xcode 26.4。版本跨度大，编译时可能遇到兼容性问题，需要根据具体报错打补丁。

面试 / 技术对话角度

面试官可能怎么问：

• 初级追问："你们团队 Xcode 版本怎么统一的？"
• 资深追问："老项目升级 Xcode 遇到编译问题你怎么处理？直接降版本还是打补丁？为什么？"

面试话术："我们用 xcodes 管理 Xcode 多版本，原理和 nvm 管理 Node 一样——每个版本是独立的 app，通过 xcode-select 切换全局激活版本。需要注意的是 macOS 和 Xcode 之间有硬性兼容约束，不是任意组合都能用。实际工作中，比起降级 Xcode，我更倾向于在新 Xcode 上针对性修复编译问题，因为社区通常有成熟的补丁方案，而且保持工具链更新有利于长期维护。"

延伸讨论

Q: 为什么不直接降级 macOS 来兼容老 Xcode？

• macOS 降级非常麻烦（需要重装系统），而且会影响所有其他开发工作
• 正确做法是在当前环境上修编译问题，或者用 CI 服务器（指定 Xcode 版本的 macOS 镜像）来构建老项目

Q: CI 环境怎么指定 Xcode 版本？

• GitHub Actions：xcode-version: '15.4' 在 workflow 里指定
• 其他 CI 平台（Jenkins、Fastlane）：通过 DEVELOPER_DIR 环境变量或 xcversion 插件指定
• 关键是 CI 的 Xcode 版本要和团队约定的一致，否则构建产物可能不同

思考题讨论

Q1：为什么 Xcode 不能像 VSCode 那样快速切换，而需要 app 级别的多安装？

用户回答：不清楚 Xcode 包含什么，为什么不能"热切换"。

暴露的知识盲区：不了解 Xcode 是一个完整的工具链集合，不是纯 IDE。

正确解答：

Xcode.app 不是单纯的 IDE，它内部捆绑了：

Xcode.app/Contents/Developer/
├── Toolchains/
│   └── XcodeDefault.xctoolchain/  ← 编译器（clang++、swiftc）
├── Platforms/
│   ├── iPhoneOS.platform/          ← iOS SDK + 头文件
│   └── iPhoneSimulator.platform/   ← 模拟器 SDK
├── Applications/
│   └── Simulator.app               ← 模拟器 app
├── usr/bin/
│   ├── xcodebuild                  ← 命令行构建工具
│   ├── instruments                 ← 性能分析工具
│   └── actool                      ← 资源编译工具
└── Library/                        ← 各种模板、脚本

每个 Xcode 版本捆绑一整套独立工具链（编译器版本、SDK 版本、模拟器运行时），之间没有任何共享。这和 Node/Python 只切换解释器不同——切 Xcode 相当于切"完整的开发环境快照"。

类比前端：想象如果 Node 16 和 Node 22 不仅是 node 二进制不同，还连带 npm、yarn、所有 polyfill、所有 devtools 都完全独立打包。那就不能通过简单改 PATH 切换，而是要管理一整套目录树。

这也解释了为什么 Xcode 安装包这么大（15GB+）：每个版本都带完整 SDK 和模拟器运行时。

Q2：如果老项目只能跑在 Xcode 14，CI 上怎么保证构建环境一致？

正确解答：

三种层级的方案，从轻到重：

方案 A：CI runner 镜像锁版本
  GitHub Actions: runs-on: macos-13 (自带 Xcode 14.x)
  + 显式 xcode-select 切到需要的版本
  → 适合公有云 CI

方案 B：Docker 化（macOS 容器）
  实际不可行 → macOS 不能在容器里跑 Xcode
  → 只能用 VM

方案 C：自建 Mac mini 专用机
  多台 Mac mini，每台固定一个 Xcode 版本
  按分支/项目路由任务
  → 大公司方案（Uber、Airbnb 都是这样）

本质：iOS 生态没有真正意义上的"环境隔离"（不像 Linux 的 Docker），只能靠机器/镜像级别的固化。这也是为什么大公司 iOS CI 基础设施比 Android 贵 10 倍。

面试话术："Xcode 的多版本管理和 Node/Python 不同，因为 Xcode 捆绑了完整工具链——编译器、SDK、模拟器都是版本绑定的。所以切换不能像 nvm 那样只改 PATH，必须管理多个 app 实例。CI 层面也因此更难标准化，我们的做法是 CI runner 锁定 macOS 版本，再用 xcode-select 显式切换——项目级别写在 fastlane 配置或 workflow 里，保证任何人在任何机器上构建产物都一致。"

系统思维：Xcode 升级节奏的成本

资深工程师做 Xcode 升级决策要算账：

实际策略：非强制期不主动升级，关注社区 release notes 和 issue tracker，等重大 bug 收敛了再升。App Store 每年大约 4-6 月强制要求新 Xcode 构建，这时候是最佳升级窗口。

3. GitLab Personal Access Token 与 postinstall 脚本机制

一句话结论

项目的 postinstall 脚本通过 GitLab API 下载内部组件库，需要 Personal Access Token 作为身份凭证；token 过期会导致 yarn install 失败。

为什么需要了解这个

yarn install 报错 Failed to download file: 403 时，如果不理解 postinstall 机制和 token 的作用，会完全不知道从哪里排查。理解这个机制后，遇到类似 403/401 错误能立刻定位到认证问题。

原理 / 本质

postinstall 钩子：package.json 中的 postinstall 脚本会在 yarn install 安装完所有 npm 包后自动执行。本项目的 postinstall 做了三件事：

yarn install 完成
    │
    ▼ 触发 postinstall
    │
    ├── 1. patch-package        ← 应用本地补丁（修改 node_modules 里的包）
    ├── 2. npx jetifier         ← Android AndroidX 兼容处理
    └── 3. node ./script/postinstall  ← 从 GitLab 下载内部组件库
                │
                ▼
        读取 src/biz-plugin/config.js 获取分支名（如 'feat/skuPrice'）
                │
                ▼
        用 PRIVATE-TOKEN 请求 GitLab API：
        https://git.hzdlsoft.com/api/v4/projects/721/repository/files/archive.zip/raw?ref=feat/skuPrice
                │
                ▼
        下载 archive.zip 并解压到 node_modules/
        （相当于手动安装了一个没发到 npm 的内部包）

Personal Access Token（个人访问令牌）：GitLab 的私有仓库不能随便让人通过 API 下载。Token 是专门给程序/脚本用的身份凭证，类似密码但：

• 可以设置过期时间
• 可以限制权限范围（只读、读写等）
• 不需要输入用户名密码

与前端已知知识的类比

相关代码位置

• package.json:6 — postinstall 脚本定义
• script/postinstall/index.js — 入口
• script/postinstall/slhComponent.js:5 — token 硬编码位置
• script/postinstall/slhComponent.js:19 — API 请求 URL 构造
• src/biz-plugin/config.js:9 — 分支名配置

三层对比

❌ 初级做法：yarn install 报错就懵了，搜错误信息碰运气
   → 不知道 postinstall 的存在，不知道去看脚本在做什么

⚠️ 中级做法：知道看 postinstall 脚本，但不理解 token 机制
   → 能定位到是下载失败，但不知道 403 和 404 分别意味着什么

✅ 资深做法：看到 403 立刻判断是认证问题，看到 404 判断是资源不存在
   → 知道去检查 token 有效性和分支是否存在
   → 会指出 token 不应该硬编码在代码里（安全隐患），应该用环境变量

面试 / 技术对话角度

面试话术："我们项目有个内部组件库没有发到 npm，而是通过 postinstall 脚本在 yarn install 后自动从公司 GitLab 下载。用的是 GitLab API + Personal Access Token 认证。我接手时遇到 403 报错，排查发现是 token 过期了。这让我意识到 token 不应该硬编码在代码里——理想做法是用环境变量或 CI 的 secret 管理，避免 token 泄露和过期后所有人都卡住。"

如何生成新 Token

1. 登录 git.hzdlsoft.com
2. 右上角头像 → Settings → 左侧 Access Tokens
3. 填名字，勾选 read_api 或 read_repository 权限，设过期时间
4. 点 Create，复制生成的 token
5. 替换 script/postinstall/slhComponent.js:5 中的旧 token

安全思维：硬编码 Token 的完整攻击面

本项目 token 硬编码在 slhComponent.js:5，这在公司内网仓库可能可接受，但资深工程师要能说出完整的风险面：

攻击面分析：

1. Git 历史泄露
   ├─ 某次误 push 到公网仓库 → token 永久进入 Git 历史
   ├─ 即使 force push 删掉，可能已被爬虫/fork 拿到
   └─ 修复代价：撤销 token + 替换所有环境

2. 构建日志泄露
   ├─ CI 日志默认公开时，curl 错误信息可能 echo 出 token
   ├─ Sentry/Bugsnag 收集的 error 堆栈可能带 token
   └─ 需要主动在日志中 mask

3. 供应链污染
   ├─ token 有 read_api 权限 → 攻击者能遍历 GitLab 项目结构
   ├─ 若误给了 write 权限 → 能推恶意代码到内部包
   └─ 最小权限原则：只给 read_repository

4. 员工离职未轮换
   ├─ token 绑定的个人账号离职后被禁用 → 所有 CI 断
   ├─ 或绑定的账号仍有权限但人已走 → 合规风险
   └─ 应该用 Project Access Token 或 Deploy Token（绑项目不绑人）

三层对比：

❌ 初级做法：token 硬编码在代码里
   → 出了问题才发现"所有人都用同一个 token，且进了 Git 历史"

⚠️ 中级做法：token 放 .env 文件 + .gitignore
   → 避免了 Git 历史泄露，但本地机器被入侵还是直接暴露
   → 多人协作时 token 分发依然混乱

✅ 资深做法：
   1. 企业级 secret manager（Vault、AWS Secrets Manager）
   2. CI 用 masked variable（GitLab CI 的 "Masked & Protected"）
   3. 本地开发用 Project Access Token（绑项目，人走不影响）
   4. 监控：token 异常使用模式告警（如突然高频下载）

postinstall 脚本是供应链攻击的高频入口

postinstall 不只是便利工具——它是npm 生态最危险的地方：

为什么 postinstall 是攻击高频点？

1. 自动执行：yarn install 时静默跑，用户不看代码
2. 有 shell 权限：能读文件、发网络请求、写 ~/.ssh
3. 依赖树深：一个 package 的 postinstall → 触发它所有依赖的 postinstall
4. 难审计：package-lock 只锁版本号，锁不住 postinstall 脚本内容

真实案例：
  - 2018 event-stream：npm 包被入侵，postinstall 窃取比特币钱包
  - 2021 ua-parser-js：postinstall 挖矿 + 窃取系统信息
  - 2024 xz-utils：供应链攻击延伸到 Linux 核心库

企业防御手段：

# 1. 审查第三方包的 postinstall 脚本
npm install --ignore-scripts  # 跳过所有 postinstall
# 然后人工检查后再运行必要的脚本

# 2. 私有 npm registry 做准入审计
# 只允许经过 security review 的包进入内部 registry

# 3. 自建 postinstall 只下载内部包，不执行任意 shell
# 本项目的做法 ✓ —— postinstall 脚本是自己写的，内容可控

本项目的 postinstall 自己写的代码 + 从自家 GitLab 下载，风险可控。但如果未来加了 --ignore-scripts，需要记得手动跑。

思考题讨论

Q1：为什么不用环境变量 + CI secret 而非要硬编码？

本质原因：历史债。项目初始化时图省事硬编码，后来"跑起来的东西不要动"惯性。

改造成本：

1. 改 slhComponent.js 读取 process.env.GITLAB_TOKEN
2. 本地开发者配 ~/.zshrc 或项目根 .env.local（加 .gitignore）
3. CI 上配 Masked Variable
4. 团队沟通 + 文档更新 + 现有硬编码 token 作废轮换

决策权衡：投入 1 天 vs 持续面对"token 过期所有人卡住"的痛苦。典型的"技术债是复利"场景——早还早便宜。

Q2：如果 postinstall 从 GitLab 下载的 zip 文件被篡改了，怎么发现？

正确解答：需要校验和机制。

// 当前代码（简化）
const archive = await download(apiUrl)
unzip(archive, 'node_modules/')

// 加校验和的安全版本
const EXPECTED_SHA = 'a3f2b1...'  // 存在代码库中，受 code review 保护
const archive = await download(apiUrl)
const actualSHA = crypto.createHash('sha256').update(archive).digest('hex')
if (actualSHA !== EXPECTED_SHA) {
  throw new Error('Archive integrity check failed')
}
unzip(archive, 'node_modules/')

对应的生态实践：

• npm 的 package-lock.json 里每个包都有 integrity 字段（sha512-xxx）
• Go modules 的 go.sum 文件
• Cargo 的 Cargo.lock 带 checksum

本项目没有这层防御，信任的是"GitLab 服务器 + 内网"的边界安全。一旦内网失守就没有第二道防线。

面试话术："我排查 postinstall 脚本 403 错误时，注意到 token 硬编码在代码里，后来做了完整的风险盘点：Git 历史泄露、构建日志 echo、离职员工、供应链污染是四个主要攻击面。虽然当前在公司内网风险可控，但我提出了改造方案——用 GitLab 的 Project Access Token 绑项目不绑人，配合 CI Masked Variable 和本地 .env.local。更根本的是加 SHA 校验——因为 postinstall 从远端下载 zip 解压到 node_modules，如果 zip 被篡改完全没有防御层。这让我建立了一个认知：postinstall 是 npm 生态安全边界最薄的地方，所有从外部下载并自动执行的脚本都需要校验和保护。"

4. Git 认证（SSH/HTTPS）vs GitLab API Token 的区别

一句话结论

git pull/push 用的是 Git 协议层的认证（SSH key 或 HTTPS 密码），GitLab API 用的是 HTTP 请求头里的 Token——两套完全独立的认证机制，互不通用。

为什么会有这个疑问

"我能拉取提交代码，为什么脚本下载文件报 403？"——因为直觉上觉得"我都登录了"，但实际上 Git 操作和 API 调用走的是不同的通道。

原理 / 本质

你日常的 git pull / git push
    │
    ▼
    SSH key（~/.ssh/id_rsa）或 HTTPS 账号密码（存在 Keychain 里）
    │
    ▼
    Git 协议层（SSH 端口 22 / HTTPS 端口 443）
    │
    ▼
    GitLab 的 Git 服务（专门处理仓库读写）


postinstall 脚本的下载请求
    │
    ▼
    PRIVATE-TOKEN（HTTP 请求头）
    │
    ▼
    HTTPS 端口 443，但走的是 REST API 路径（/api/v4/...）
    │
    ▼
    GitLab 的 API 服务（处理项目管理、文件下载等）

关键区别：虽然都是访问同一个 GitLab 服务器，但 Git 服务和 API 服务是两个独立的入口，各自有各自的认证方式。SSH key 只在 Git 协议层有效，API 层完全不认。

与前端已知知识的类比

类似于：你用 GitHub 账号密码能 git push，但要调用 GitHub API（比如创建 issue、下载 release）时需要单独生成一个 GitHub Token。同一个平台，两套认证。

面试 / 技术对话角度

面试话术："Git 操作和 GitLab API 是两套独立的认证体系。Git 走 SSH 或 HTTPS 协议层，API 走 HTTP 请求头的 Token。我在排查 postinstall 脚本 403 错误时搞清楚了这个区别——之前一直以为能 git pull 就等于'已登录'，实际上 API 需要单独的 Personal Access Token 授权。这个认知也适用于 GitHub、Bitbucket 等所有 Git 托管平台。"

延伸讨论

Q: 有没有一种凭证能同时用于 Git 和 API？

• Personal Access Token 其实也可以用于 Git HTTPS 认证（当密码用），但 SSH key 不能用于 API
• 所以如果你用 PAT 做 Git HTTPS 认证，理论上同一个 token 能访问 API，但反过来不行

三层对比

❌ 初级做法：遇到 403/401 就换个 token 试试
   → 不理解认证体系，碰运气，token 泄露风险

⚠️ 中级做法：知道 API 要用 token，但不理解为什么 SSH key 不能
   → 能解决问题，但没法解释清楚
   → 面试答"就是这样规定的"

✅ 资深做法：理解 "认证 vs 授权" 分层
   → SSH key = 身份证（你是谁，用于 Git 协议层）
   → PAT = 临时门禁卡（你能做什么，用于 API 层，可限制 scope 和有效期）
   → 每种凭证有设计目的，不能混用
   → 能给团队设计"最小权限"的凭证方案

系统思维：多平台凭证管理的演进

一个公司往往同时接入多个平台（GitLab、GitHub、Artifactory、npm private registry、阿里云），每个都要凭证。资深工程师知道怎么系统性管理：

演进路径：

阶段 1（<10人）：每人手动维护各自的凭证
  凭证分散：~/.ssh、~/.npmrc、~/.zshrc、环境变量
  问题：一个人配一次、离职交接混乱、无法审计
  
  ↓

阶段 2（10-50人）：集中配置文档 + 脚本分发
  新人入职按文档跑一个 setup.sh
  问题：文档会过期、凭证仍散落在各开发者机器
  
  ↓

阶段 3（50+人）：企业级 Secret Manager
  HashiCorp Vault / AWS Secrets Manager / Doppler
  CLI 工具 authenticated 后动态拉凭证（不落地）
  问题：基础设施投入，团队培训
  
  ↓

阶段 4（大厂）：零信任 + 身份联合
  所有服务走 SSO（Okta/AAD）→ 短期 token 动态签发
  开发者不持有长期凭证，每次用都要重新认证
  好处：离职即失效，审计完整

本项目处在阶段 1-2 过渡：token 硬编码 + 靠人记住要轮换。这是中型团队的典型状态。

安全思维：凭证暴露的"爆炸半径"对比

SSH Key 泄露 vs PAT 泄露：

SSH Key（~/.ssh/id_rsa）：
  ├─ 能：git clone/push（仓库读写）
  ├─ 不能：GitLab API（查 issue、改 settings、下 artifact）
  ├─ 撤销：在 GitLab 页面删除 public key → 即时生效
  └─ 爆炸半径：中（仓库级别）

PAT（Personal Access Token）：
  ├─ 能：取决于勾选的 scope（read_api/write_api/read_repo/...）
  ├─ 最危险：api 权限 = 模拟你的完整操作，能改 settings、删 project
  ├─ 撤销：在 GitLab → Settings → Access Tokens 点 Revoke
  └─ 爆炸半径：可能极大（取决于权限）

→ 最小权限原则：PAT 只勾选实际需要的 scope
→ 本项目 postinstall 只需要 read_repository（下载文件），不需要 api

思考题讨论

Q1：为什么 SSH key 不能用于 API？

用户回答：不清楚底层机制。

暴露的知识盲区：不理解传输协议和应用协议的分层。

正确解答：

SSH key 的使命是做 SSH 协议层的身份验证，它的工作流程：

git push 时发生了什么：

客户端                                          服务端
  │                                              │
  │──── 1. TCP 连接 ssh://git@gitlab.com:22 ───▶│
  │                                              │
  │◀─── 2. 服务端发送随机 challenge ──────────────│
  │                                              │
  │   3. 用私钥对 challenge 签名                  │
  │                                              │
  │──── 4. 发送签名 ───────────────────────────▶│
  │                                              │
  │            5. 服务端用 public key 验证签名    │
  │                                              │
  │◀─── 6. 认证通过，建立 SSH tunnel ─────────────│
  │                                              │
  │──── 7. 在 tunnel 里跑 git protocol ────────▶│

SSH key 在第 3-5 步完成了"证明你是谁"这件事，之后整个 SSH tunnel 就是可信通道。

而 HTTP API 是完全不同的世界：

调用 GitLab API：

客户端                                          服务端
  │                                              │
  │──── 1. HTTPS 连接 https://gitlab.com:443 ──▶│
  │     （TLS 证书验证服务端，但不认证客户端）     │
  │                                              │
  │──── 2. POST /api/v4/projects ──────────────▶│
  │     Headers: PRIVATE-TOKEN: abc123           │
  │                                              │
  │            3. 服务端读 header 验证 token      │
  │                                              │
  │◀─── 4. 200 OK ────────────────────────────────│

HTTP 协议层完全不认 SSH key——HTTP 服务端读的是 header，SSH 服务端做的是 tunnel 内的挑战响应。这是两个不同 OSI 层的认证机制，天然不通。

类比：SSH key = 进公司大楼刷的门禁卡。能让你进楼，但进了楼之后你要用公司邮箱账号登内网系统——邮箱系统看不懂你的门禁卡。

Q2：为什么 PAT 可以用于 Git HTTPS 但 SSH key 不能用于 API？

不对称的本质：

Git 协议支持两种传输通道：
  ├─ SSH 通道：用 SSH key 认证（无密码概念）
  └─ HTTPS 通道：用"用户名+密码"认证（和普通 HTTP 一样）

PAT 的设计：
  就是一种"密码替代品"，能用在任何"需要密码的地方"
  → HTTPS Git 需要密码？把 PAT 当密码填进去，成立
  → 包括 git clone https://user:TOKEN@gitlab.com/repo

SSH key 的设计：
  只能通过 SSH 协议的挑战-响应握手使用
  → HTTP API 根本没有 SSH 握手步骤，用不上

所以：PAT 是"万能钥匙"（能用在密码槽和 API header），SSH key 是"专用钥匙"（只开 SSH 锁）。

面试话术："Git 认证和 API 认证是不同协议层的两套机制——SSH key 在 TCP 层做挑战-响应握手，PAT 在 HTTP 层作为 header 传递。PAT 之所以能兼用 Git HTTPS，是因为 HTTPS Git 本质上是用户名密码认证，PAT 充当密码；但反过来 SSH key 只能在 SSH 握手里用，HTTP API 没有对应的握手步骤。理解这个让我在排查 postinstall 403 时立刻想到要换 PAT 而不是去折腾 SSH 配置。工程上的启示是：'能 git pull 就等于已登录'是错觉——不同协议层的授权要分开看。"

Q3：为什么有些公司完全禁用 SSH，只允许 HTTPS + PAT？

典型安全考虑：

1. SSH key 默认无过期：生成一次用终身，容易变成"孤儿凭证"（离职员工的 key 还能用）
2. SSH key 难审计：GitLab 能看到用了哪个 key，但没有"细粒度 scope"
3. PAT 可以强制过期：30 天/90 天自动失效，必须定期轮换 → 暴露窗口有限
4. PAT 可以限 scope：只读/只写/限 IP，比 SSH key 精细
5. HTTPS 更好穿墙：SSH 端口 22 经常被企业防火墙封，HTTPS 443 通用

代价：

• 开发者每次 push 要输 token（可用 credential helper 缓存）
• PAT 到期时要轮换，比 SSH key 麻烦

这是"安全性 vs 开发便利"的权衡，大厂（金融/医疗行业）通常选安全性。

5. Xcode 26 适配 RN 0.66 项目：7 个编译补丁全记录

一句话结论

React Native 0.66（2021年）+ Xcode 26（2026年）跨越 5 年版本差距，需要 7 个补丁才能在模拟器上跑通，涉及 C/C++ 头文件、Swift import、Objective-C 私有 API、linker 行为变更等多个层面。

为什么需要了解这个

老项目 + 新工具链是中大型公司的常态。理解"为什么编译会碎、碎在哪一层、怎么系统性修复"是资深工程师的核心能力之一。这不是背答案能解决的——每次 Xcode 升级碎的地方都不一样，关键是掌握排查方法论。

原理 / 本质

iOS 编译流程有多个阶段，每个阶段都可能因新工具链而失败：

pod install
    │
    ▼ 生成 Pods.xcodeproj
    │
源代码编译（C/C++/ObjC/Swift）  ← 补丁 1-6 修的是这里
    │
    ▼ 生成 .o 目标文件
    │
链接（Linking）                  ← 补丁 7 修的是这里
    │
    ▼ 生成 .app
    │
签名 & 安装到模拟器/设备

新 Xcode 带来的变化分三类：

1. SDK 变化：头文件移动/私有化（netinet6/in6.h）、类型重定义（clockid_t）
2. 编译器变化：Clang 更严格（链式比较变 error）、Swift 不再隐式导入 UIKit
3. 链接器变化：要求 .o 文件 8 字节对齐、最低部署目标 ≥ 12.0

7 个补丁详解

补丁 1：glog config.h 宏定义缺失

• 现象：unknown type name '_START_GOOGLE_NAMESPACE_'，一大片 glog 编译错误
• 根因：glog 是 React Native 的 C++ 日志库。它需要一个 config.h 配置文件，本该由 pod install 时的 ./configure 脚本生成，但 RN 0.66 的 configure 脚本在新系统上没有正确执行，生成的 config.h 只有 15 行（应该有 60+ 行），缺少 GOOGLE_NAMESPACE、HAVE_PTHREAD 等关键宏定义
• 修复：在 Podfile 的 post_install 中直接写入完整的 config.h
• 文件：ios/Podfile（post_install 脚本）→ 自动修改 Pods/glog/src/config.h

❌ 初级做法：看到一堆 C++ 错误就懵了，搜索每个错误试图逐个修
⚠️ 中级做法：知道是 glog 的问题，尝试重新 pod install
✅ 资深做法：查看 config.h 发现宏定义缺失，对比 config.h.in 模板，
   直接补全配置 → 理解 autoconf/configure 机制是 C/C++ 项目的标配

补丁 2 & 3：netinet6/in6.h 私有头文件

• 现象：Use of private header from outside its module: 'netinet6/in6.h'
• 根因：iOS 26 SDK 将 netinet6/in6.h 标记为私有头文件，不再允许外部模块直接引用。但 netinet/in.h 已经包含了 IPv6 的定义（struct sockaddr_in6 等），所以 netinet6/in6.h 本来就是多余的 import
• 修复：删除 #import <netinet6/in6.h> 行
• 文件：ios/Podfile（post_install 脚本）→ 自动修改 AFNetworking 和 YKAsihttp 的 3 个 .m 文件

补丁 4：Texture 链式比较

• 现象：chained comparison 'X < Y < Z' does not behave the same as a mathematical expression
• 根因：C/C++ 中 a < b < c 不是数学上的"a 小于 b 小于 c"，而是 (a < b) < c，即先比较得到 0 或 1，再和 c 比较。新版 Clang 把这个从 warning 升级为 error
• 修复：改为三元表达式 (a < b) ? prev : next，这才是代码原本的语义
• 文件：ios/Podfile（post_install 脚本）→ 自动修改 Pods/Texture/.../ASTextLayout.mm

❌ 初级做法：看到 error 就加 -Wno-parentheses 禁用警告
⚠️ 中级做法：加括号 (a < b) < c 消除 error 但不改逻辑
✅ 资深做法：分析原始语义，发现 < 应该是 ?:（三元运算符），修正逻辑 bug

补丁 5：Folly clockid_t 类型重定义

• 现象：typedef redefinition with different types ('uint8_t' vs 'enum clockid_t')
• 根因：RCT-Folly（Facebook 的 C++ 基础库）认为 iOS 没有 clock_gettime，自己 typedef 了一个 clockid_t。但 iOS 10+ 就有了 clock_gettime，iOS 26 SDK 的 clockid_t 是 enum 类型，和 Folly 的 uint8_t typedef 冲突
• 修复：在 Folly 的 Time.h 中加一段 guard：如果 iOS ≥ 10.0 或 macOS ≥ 10.12，定义 FOLLY_HAVE_CLOCK_GETTIME = 1，跳过自定义 typedef
• 文件：ios/Podfile（post_install 脚本）→ 自动修改 Pods/RCT-Folly/folly/portability/Time.h

补丁 6：libarclite 缺失 + 部署目标

• 现象：SDK does not contain 'libarclite' at the path
• 根因：libarclite 是 ARC（自动引用计数）的兼容库，用于支持 iOS 11 以下的旧设备。Xcode 26 已经移除了这个库，因为 iOS 12+ 原生支持 ARC。部分 pod（如 Charts、SSZipArchive）的部署目标设为 iOS 9.0，触发了对 libarclite 的依赖
• 修复：在 Podfile 的 post_install 中，将所有 pod 的 IPHONEOS_DEPLOYMENT_TARGET 提升到至少 13.0
• 文件：ios/Podfile

补丁 7：CorePlot 库对齐 + -ld_classic

• 现象：64-bit mach-o member 'CPTFunctionDataSource.o' not 8-byte aligned
• 根因：CorePlot 是一个图表库，它的静态库 libCorePlot-CocoaTouch.a 是很久以前编译的，内部的 .o 文件没有 8 字节对齐。Xcode 26 的新 linker 要求严格对齐
• 修复：在项目的 OTHER_LDFLAGS 中加入 -ld_classic，使用旧版 linker 来容忍对齐问题
• 文件：ios/slh_new.xcodeproj/project.pbxproj（Debug 和 Release 两个配置都加了）

❌ 初级做法：看到 linker error 完全没方向
⚠️ 中级做法：尝试 libtool 重新打包 .a 文件（但可能丢失架构 slice）
✅ 资深做法：知道 -ld_classic 回退旧 linker 是安全的临时方案，
   长期方案是更新 CorePlot 或用源码重新编译

额外修复：import UIKit

• 现象：cannot find type 'UIColor' in scope
• 根因：BalloonMarker.swift 和 XYMarkerView.swift 只 import 了 Foundation 和 Charts，没有 import UIKit。Swift 不像 ObjC 那样有"伞头文件"自动导入所有框架，每个 Swift 文件必须显式 import 用到的模块
• 修复：两个文件加 import UIKit
• 文件：ios/slh_new/CustomerPortrait/View/BalloonMarker.swift、XYMarkerView.swift

排查方法论总结

编译报错
   │
   ├── 看错误在哪个 target → 确定是 Pod 的问题还是项目代码的问题
   │
   ├── 看错误类型：
   │   ├── "cannot find type" → 缺 import 或模块没编译出来
   │   ├── "typedef redefinition" → 新旧 SDK 类型定义冲突
   │   ├── "private header" → SDK 头文件权限变更
   │   ├── "not 8-byte aligned" → linker 严格性变更
   │   └── "libarclite" → 部署目标过低
   │
   └── 修复策略：
       ├── Pod 的问题 → 写在 Podfile post_install，pod install 自动打补丁
       ├── 项目代码问题 → 直接改源文件
       └── linker 问题 → 改项目 build settings

持久化策略

相关代码位置

• 补丁脚本：ios/Podfile:123-220（# ===== Xcode 26 compatibility patches ===== 区块）
• linker flag：ios/slh_new.xcodeproj/project.pbxproj（搜索 -ld_classic）
• Swift import：ios/slh_new/CustomerPortrait/View/BalloonMarker.swift:13、XYMarkerView.swift:8

面试 / 技术对话角度

面试官可能怎么问：

• 初级追问："你有没有遇到过 Xcode 升级后项目编不过的情况？"
• 资深追问："你是怎么系统性排查的？怎么确保补丁不会被 pod install 覆盖？"

面试话术："我们有个 RN 0.66 的老项目需要在 Xcode 26 上跑，跨了 5 年版本。我系统性地解决了 7 个兼容性问题，涵盖 C++ 配置文件缺失、SDK 私有头文件变更、类型重定义冲突、编译器严格性升级、linker 行为变更等。关键经验是：Pod 的补丁必须写在 Podfile 的 post_install 里，否则每次 pod install 会被覆盖；项目级的改动（linker flag、Swift import）直接改源文件。整个过程的方法论是先定位错误在编译流程的哪个阶段，再针对性修复——不是碰运气搜 Stack Overflow，而是理解每个错误的根因。"

延伸讨论

Q: 为什么不直接升级 RN 到新版本？

• RN 0.66 → RN 0.76+（最新）是一次巨大的升级，涉及新架构（Fabric、TurboModules）、Hermes 引擎替换、所有原生模块的 API 变更。对一个成熟项目来说，这是几周到几个月的工作量。如果只是临时修 bug，打补丁跑通是正确的务实选择
• 权衡：补丁方案的维护成本是每次 Xcode 升级可能需要新补丁；升级 RN 的前期成本高但长期维护更轻松。根据业务优先级决定

Q: -ld_classic 有什么风险？

• 旧版 linker 可能不支持一些新特性（比如 mergeable libraries），但对大多数场景没有影响
• 长期方案是用新版 CorePlot 或从源码重新编译 libCorePlot-CocoaTouch.a

Q: 为什么命令行 xcodebuild 能成功但 Xcode IDE 报错？

• Xcode IDE 有一个独立的索引器（SourceKit），它会在后台解析代码并显示错误提示。如果某个 framework 还没被编译出来，索引器会报"找不到类型"的错误，但这不是真正的编译错误
• 命令行 xcodebuild 按正确的依赖顺序编译所有 target，所以不会有这个问题
• 解决办法：先用命令行编译一次，让所有 framework 产物就位，然后 Xcode 的索引器就能找到它们了

6. Hybrid App 架构：Native + RN 混合开发模式

一句话结论

本项目不是"RN 套壳 App"，而是原生为主、RN 渐进式嵌入的混合架构——核心业务流程是原生 ObjC，特定功能模块（打印、扫码、AI 助手、报表）用 RN 实现。

为什么这个架构值得学习

大部分教程教的是"纯 RN App"或"纯原生 App"。但企业级 App 几乎都是混合的——老业务用原生，新需求用 RN/Flutter 渐进迁移。理解这种架构模式是做大型移动项目的必备认知。

原理 / 本质

┌─────────────────────────────────────────────┐
│                  AppDelegate                 │
│          初始化 RCTBridge（全局唯一）           │
└────────────────────┬────────────────────────┘
                     │
        ┌────────────┴────────────┐
        ▼                         ▼
  原生 ViewController          RN ViewController
  (UIKit, ObjC)               (托管 RCTRootView)
        │                         │
        │    ┌────────────┐       │
        └───▶│ 共享 Bridge │◀──────┘
             └────────────┘
                  │
        ┌─────────┼─────────┐
        ▼         ▼         ▼
   打印模块   扫码模块   AI助手
   (RN页面)  (RN页面)   (RN页面)

核心设计：所有 RN 页面共享一个 RCTBridge 实例（存在 AppDelegate 上），原生 ViewController 通过 RCTRootView 托管 RN 组件。

关键代码

原生 VC 嵌入 RN 页面（ios/slh_new/Printer/YKPrintTaskViewController.m）：

// 从 AppDelegate 获取共享的 Bridge
RCTBridge *bridge = ((AppDelegate *)[UIApplication sharedApplication].delegate).bridge;

// 用 Bridge 创建 RCTRootView，指定 RN 模块名 + 初始参数
self.rootView = [[RCTRootView alloc] initWithBridge:bridge
                                          moduleName:@"PrintTaskScreen"
                                  initialProperties:initialProperties];
self.view = self.rootView;

RN 端注册多个独立模块（src/App.tsx:37-66）：

// 每个功能模块独立注册，不是传统的 Stack Navigation
AppRegistry.registerComponent('PrintTaskScreen', () => PrintTaskScreen)
AppRegistry.registerComponent('ScanScreen', () => ScanScreen)
AppRegistry.registerComponent('CommissionScreen', () => CommissionScreen)

与纯 RN 项目的对比

三层对比

❌ 初级做法：把整个 App 用 RN 重写
   → 开发周期长、原生能力受限、性能瓶颈明显

⚠️ 中级做法：知道可以混合，但每个 RN 页面创建独立 Bridge
   → Bridge 初始化很重（~200ms+），多 Bridge 浪费内存

✅ 资深做法：共享 Bridge + 按需嵌入 RN 页面
   → 一次初始化，多处复用
   → 原生负责核心流程和性能敏感操作
   → RN 负责快速迭代的 UI 模块

面试话术

面试话术："我们的 App 是原生为主的 Hybrid 架构，核心业务用 ObjC，新功能模块（打印、报表、AI）用 React Native。所有 RN 页面共享一个 RCTBridge 实例，原生 ViewController 通过 RCTRootView 按需嵌入 RN 组件，通过 initialProperties 传递参数。这种架构的好处是：原生部分保持高性能，RN 部分支持热更新（CodePush），两边通过 NativeModules 和 EventEmitter 双向通信。"

思考题讨论

Q1：如果 JS 侧崩了，整个 App 会挂吗？

用户回答：不清楚 JS 线程和原生线程的隔离性。

暴露的知识盲区：对 RN 的线程模型没有认知——不知道 JS 线程独立于主线程。

正确解答：

RN 是多线程架构，关键在于 JS 线程和原生 UI 线程是分开的：

iOS 主线程（UI Thread）
   ├── 原生 ViewController 的生命周期
   ├── UIKit 渲染、用户手势
   └── 不被 JS 错误影响

JS 线程（Bridge 持有，独立线程）
   ├── 执行 React 组件渲染
   ├── 业务逻辑
   └── 崩溃 → 只影响当前 RN 页面

Shadow Thread（Yoga 布局计算）
   └── RN 页面的 flexbox 计算

Native Modules Thread
   └── 原生模块回调

崩溃隔离实测：

场景 A：JS 代码抛未捕获异常
  → Bridge 捕获 → RN 页面显示红屏（Debug）或白屏（Release）
  → 原生页面不受影响，用户可以 back 回原生页面继续用
  → 相当于"RN 子应用"挂了

场景 B：JS 死循环（while(true)）
  → JS 线程卡住，RN 页面冻结
  → 但原生导航条还能响应，用户可以退出
  → Bridge 的消息队列堆积，恢复后会补发

场景 C：Bridge 本身崩溃（极少见）
  → Native Module 调用失败，RN 全部不可用
  → 原生部分继续工作
  → 通常伴随 RCTBridge 报错，可以重建 Bridge 恢复

对比纯 RN 和纯原生：

这就是 Hybrid 架构的韧性优势：把 RN 当成"高危实验区"，核心路径用原生保证稳定。

Q2：共享 Bridge 的代价是什么？

正确解答：

共享 Bridge 不是免费的，代价在于：

共享 Bridge 的隐藏成本：

1. 内存生命周期错位
   ├─ RN 页面关闭后，组件从 RCTRootView 卸载
   ├─ 但 JS 闭包、全局对象、定时器 **不会**被回收
   ├─ 长时间使用后内存增长（典型泄漏场景）
   └─ 纯原生页面关闭后内存立刻释放，RN 共享 Bridge 没这个好处

2. 跨页面状态污染
   ├─ 页面 A 在 PrintSvc 里存了数据
   ├─ 关闭 A、打开 B → B 能读到 A 的脏数据
   └─ 需要显式清理：在页面卸载时主动 reset service 状态

3. 单点故障
   ├─ Bridge 崩溃 → 所有 RN 页面不可用（不只是当前页面）
   ├─ 需要 Bridge 级别的 error boundary（RCTFatalHandler）
   └─ 或者实现"Bridge 重建"逻辑（耗时，用户体验差）

4. 模块注册冲突
   ├─ 多个 RN 页面都想注册 'MainScreen' → 后注册的覆盖前面的
   └─ 必须全局协调模块名

权衡总结：

共享 Bridge：
  ✅ 启动快（一次初始化）
  ✅ 内存省（一个 JS 引擎实例）
  ❌ 状态泄漏风险
  ❌ 单点故障

独立 Bridge（每页面一个）：
  ❌ 启动慢（每次 ~400ms）
  ❌ 内存高（每个几十 MB）
  ✅ 崩溃隔离
  ✅ 状态干净

→ 主流选择：共享 Bridge + 严格的生命周期管理
→ 极端场景（安全要求高）才用独立 Bridge

面试话术："共享 Bridge 不是免费午餐。启动快、省内存是好处，但需要配套的状态管理纪律——RN 页面卸载时要手动清理 Service 状态、解绑 EventEmitter、清理定时器，否则多次进出同一页面会内存泄漏。另一个隐藏成本是 Bridge 单点故障——崩了就所有 RN 不可用。我们的做法是在 AppDelegate 里实现 bridge 重建逻辑，检测到 Bridge 异常时 rebuild，代价是用户会看到 1-2 秒白屏，但避免了整个 App 重启。"

系统思维：Hybrid 架构的演进路径

大部分企业 App 都会经历 "纯原生 → Hybrid → 渐进迁移" 的过程：

时间线上的典型演进：

Year 0-3：纯原生
  ├─ iOS 团队写 Swift，Android 团队写 Kotlin
  ├─ 新功能双端各实现一次
  └─ 瓶颈：人力成本高，双端不同步

Year 3-5：引入 Hybrid
  ├─ 非核心模块用 RN/Flutter 复用代码
  ├─ 核心流程（支付、登录、首页）保留原生
  └─ 挑战：Bridge 维护成本，原生 & RN 两套状态管理

Year 5+：分化
  ├─ 选项 A：全面 RN 化 → 性能关键点用 native modules 补
  │   → 典型：Discord、Shopify
  ├─ 选项 B：保持 Hybrid → 根据模块特性选技术
  │   → 典型：Meta Messenger、Microsoft Office
  └─ 选项 C：切 Flutter → 统一渲染引擎
      → 典型：字节跳动部分业务线

本项目目前在 Hybrid 稳态。要再进化，关键决策点是："核心流程的热更新需求" vs "性能和原生体验"——前者选 RN 迁移，后者保持现状。

7. Native Bridge 双向通信机制

一句话结论

RN 和原生之间的通信分两条路：RN → Native 走 NativeModules（主动调用），Native → RN 走 EventEmitter（事件推送）。两者互不干扰，各有适用场景。

原理 / 本质

        RN 侧                                    Native 侧
   ┌─────────────┐                          ┌─────────────────┐
   │  JS 代码     │                          │  ObjC 代码       │
   │             │     RN → Native           │                 │
   │ NativeModules ──────────────────────▶ RCT_EXPORT_METHOD  │
   │ .DLRNDevice │   （调用+Promise/回调）     │                 │
   │ Module.xxx()│                          │                 │
   │             │     Native → RN           │                 │
   │ eventEmitter◀──────────────────────── NSNotificationCenter│
   │ .addListener│   （事件推送，异步）         │ → RCTEventEmitter│
   └─────────────┘                          └─────────────────┘

关键代码

RN → Native（主动调用，Promise 风格）

Native 端暴露方法（ios/slh_new/RNModules/DLRNDeviceModule.m）：

RCT_EXPORT_METHOD(networkCommonParams:(RCTPromiseResolveBlock)resolve
                  rejecter:(RCTPromiseRejectBlock)reject) {
    NSMutableDictionary *params = [[NSMutableDictionary alloc] init];
    setupDictValue(params, @"serverUrl", my_gs.g_current_server_url);
    setupDictValue(params, @"sessionId", MyHttpUtil.g_sessionId);
    setupDictValue(params, @"isTest", @([g_isTestServer boolValue]));
    resolve(params);
}

RN 端调用：

const params = await NativeModules.DLRNDeviceModule.networkCommonParams()
// params = { serverUrl, sessionId, isTest, ... }

Native → RN（事件推送）

Native 端发送事件（ios/slh_new/RNModules/YKRNSendEventManager.m）：

// 任何原生代码都可以通过 NSNotificationCenter 触发
[[NSNotificationCenter defaultCenter] postNotificationName:@"yk_onPrinterAdd"
                                                    object:nil
                                                  userInfo:@{@"data": printerInfo}];

// YKRNSendEventManager 收到通知后转发给 RN
- (void)onNotification:(NSNotification *)notification {
    [self sendEventWithName:notification.name body:notification.userInfo];
}

RN 端监听：

const emitter = new NativeEventEmitter(NativeModules.YKRNSendEventManager)
emitter.addListener('yk_onPrinterAdd', (data) => {
    // 处理打印机添加事件
})

什么时候用哪种

三层对比

❌ 初级做法：所有通信都用回调
   → 形成 callback hell，Native 发起的事件无法推送

⚠️ 中级做法：知道 NativeModules 和 EventEmitter，但混用
   → 该用 Promise 的地方用了事件，增加复杂度

✅ 资深做法：根据通信方向和语义选择模式
   → RN 主动请求 → NativeModules（同步语义，Promise/回调）
   → Native 主动推送 → EventEmitter（异步语义，发布/订阅）
   → 两者通过 NSNotificationCenter 解耦，任何原生代码都能触发 RN 事件

面试话术

面试话术："RN 和原生的通信我们分两种模式：RN 主动调用原生走 NativeModules，支持 Promise 和回调，适合请求/响应场景；原生主动推送给 RN 走 RCTEventEmitter，基于发布/订阅模式，适合状态变化通知。我们的实现中，原生任何地方只需要发一个 NSNotificationCenter 通知，RNSendEventManager 会统一转发给 JS 层，做到了完全解耦。"

性能思维：Bridge 通信的隐藏成本

Bridge 通信不是函数调用，是跨线程序列化消息。资深工程师必须理解这个成本：

NativeModules.DLRNDeviceModule.networkCommonParams() 的实际开销：

JS 线程：
  1. 序列化参数为 JSON 字符串        ← ~1-5ms
  2. 把消息放进 Bridge 的 MessageQueue ← ~0.5ms
                                      │
                                      ▼
  原生线程（异步执行）：
  3. 从 MessageQueue 取消息            ← ~0.5ms
  4. JSON 反序列化                      ← ~1-5ms
  5. 执行原生方法                       ← 业务时间
  6. 序列化返回值为 JSON                ← ~1-5ms
  7. 通过 Promise resolve 回 JS 线程    ← ~1ms

总开销（不算业务）：~5-20ms

这意味着什么？

❌ 反模式：高频调用 Bridge
  for (let i = 0; i < 1000; i++) {
    await NativeModules.LogModule.log(`item ${i}`)
  }
  → 20s+，UI 卡死

✅ 批处理：
  await NativeModules.LogModule.logBatch(items)
  → 20ms，一次搞定

❌ 反模式：传大对象
  await NativeModules.ImageModule.process(base64_10MB_image)
  → 序列化耗时 100ms+，UI 掉帧

✅ 传引用：
  const imageId = saveToNativeCache(image)
  await NativeModules.ImageModule.process(imageId)
  → 只传 ID 字符串，原生按 ID 取图

三层对比

❌ 初级做法：有啥调啥，不考虑调用频率和数据量
   → 高频 Bridge 调用导致卡顿
   → 传大对象导致序列化瓶颈

⚠️ 中级做法：知道要批量，但不理解为什么
   → 偶尔批量，大多数地方还是一次一调用

✅ 资深做法：
   → 理解"Bridge = 异步消息队列"心智模型
   → 设计 API 就考虑批量接口
   → 大数据走引用传递（文件路径、缓存 ID）
   → 实时性要求高的场景考虑 JSI（RN 0.60+ 的同步调用替代方案）

思考题讨论

Q1：为什么 RN 要引入 JSI (JavaScript Interface) / TurboModules / Fabric 新架构？

用户回答：不清楚新架构要解决什么。

正确解答：

老 Bridge 架构的根本限制：

老 Bridge：
  - 所有 JS ↔ Native 通信走异步消息队列
  - 基于 JSON 序列化
  - 批量调度，有延迟

限制：
  1. 不能同步调用 → 写起来到处 await
  2. JSON 开销大 → 大对象传输卡
  3. 消息队列阻塞 → 高频场景掉帧
  4. 冷启动慢 → 所有模块启动时注册

JSI 的革命：

JSI 允许 JS 持有"原生对象"的 C++ 引用：

老方式：
  NativeModules.FooModule.bar()
  → JS 编码 → 队列 → 原生解码 → 执行 → 编码回传 → JS 解码
  
JSI 方式：
  global.FooModule.bar()  // 直接在 JS 引擎里调 C++ 函数
  → 零序列化，同步执行，纳秒级开销

TurboModules & Fabric：

• TurboModules = 基于 JSI 的 NativeModules 替代品，同步 + 懒加载
• Fabric = 基于 JSI 的新渲染管线，更细粒度的 UI 更新

本项目现状（RN 0.66）：仍在老 Bridge 架构。升级到新架构（需要 RN 0.70+）会有显著性能提升，但迁移成本大（所有 native module 要改）。

Q2：EventEmitter listener 忘记 remove 会怎样？

用户回答：不清楚 listener 的生命周期。

正确解答：

经典的 "Listener Leak" 问题：

// ❌ 错误：每次组件挂载添加 listener，卸载时不移除
function MyScreen() {
  useEffect(() => {
    const emitter = new NativeEventEmitter(YKRNSendEventManager)
    emitter.addListener('yk_onPrinterAdd', (data) => {
      setPrinterList([...printers, data])  // ← 闭包捕获了 printers
    })
    // 缺少清理！
  }, [])
}

// 进出这个页面 10 次后：
// - 10 个 listener 堆积在 EventEmitter 内部数组
// - 每次打印机事件触发 → 10 个 callback 同时执行
// - 10 个 callback 各自持有不同版本的 printers 闭包
// - setPrinterList 被调 10 次，性能 + 逻辑 bug

危害：

1. 内存泄漏：闭包里的组件状态 + DOM 引用永远不释放
2. 性能退化：事件触发成本 × 历史 listener 数
3. 逻辑错误：旧 listener 持有的 state 是过期的 closure

正确做法：

useEffect(() => {
  const emitter = new NativeEventEmitter(YKRNSendEventManager)
  const sub = emitter.addListener('yk_onPrinterAdd', handlePrinterAdd)
  return () => sub.remove()  // ← cleanup
}, [])

类比前端：这和 Web 的 addEventListener 必须对应 removeEventListener 完全一致。RN EventEmitter 本质就是跨线程版本的 EventTarget。

Q3：怎么排查 "page 打开很慢" 的 Bridge 瓶颈？

正确解答：

排查工具链：

1. Systrace / Perfetto（Android）/ Instruments（iOS）
   → 看 JS 线程和 Native 线程的活动，找到阻塞点

2. 自制打点：
   const t0 = performance.now()
   await NativeModules.Foo.bar()
   console.log(`bar took ${performance.now() - t0}ms`)

3. Flipper 的 React DevTools + Network tab
   → 看 Bridge 消息流量

4. 对比 Debug vs Release
   → Debug 模式 Bridge 走 WebSocket，慢 5-10 倍
   → 只有 Release 的数据才有参考价值

常见瓶颈模式：

面试话术："Bridge 通信本质是异步消息队列 + JSON 序列化，每次调用 5-20ms 开销。我在项目中遇到过页面打开慢的问题，排查发现是首屏串行调了 6 个 native module 获取设备信息、用户信息、配置信息——总共 100ms+。优化方案是合并成一个 batch 接口 getInitialContext()，一次调用返回所有数据，直接降到 15ms。这让我建立了一个原则：每一次 Bridge 调用都是成本，API 设计阶段就要按'批量优先'来考虑。更根本的解决是迁移到 JSI/TurboModules，但那是架构级别的工程。"

8. Service 单例 + Provider 模式：轻量级状态管理

一句话结论

本项目没有用 Redux/MobX 做全局状态管理，而是用 Service 单例持有业务状态 + React Context Provider 分发配置，更轻量、更贴合 Hybrid 架构。

为什么这个模式值得学习

很多前端工程师一上来就上 Redux，但企业项目中（尤其是 Hybrid App），全局状态并不多——大部分状态由原生管理，RN 只负责局部 UI。这时候 Service 单例 + Provider 是更合理的选择。

架构图

原生层（ObjC）
   │
   │ 通过 NativeModules 传入
   ▼
┌─────────────────────────────┐
│ Service 单例（TypeScript）     │
│                             │
│ PrintSvc.getInstance()      │ ← 持有打印机列表、配置、状态
│ MqttSvc.getInstance()       │ ← 持有 MQTT 连接状态
│ UserActionSvc.getInstance() │ ← 持有用户行为追踪
│                             │
│ 特点：                       │
│ - 生命周期跟随 App           │
│ - 懒加载数据                 │
│ - 通过 registerHandler 注册  │
│   异步回调                   │
└─────────────────────────────┘
              │
              ▼
┌─────────────────────────────┐
│ React Context Provider      │
│                             │
│ <SLHProvider value={{       │
│   appName, locale,          │ ← 配置信息，不变或很少变
│   fontScaleLevel, dev,      │
│   dllog, theme              │
│ }}>                         │
│   <业务组件 />               │
│ </SLHProvider>              │
└─────────────────────────────┘

关键代码

Service 单例（src/svc/PrintSvc.ts）：

class PrintSvc {
  private printerTypesData: any[] = []    // 业务状态
  private rfidTplTypes: any[] = []

  async loadPrinterType() {               // 懒加载
    if (this.printerTypesData.length > 0) return this.printerTypesData
    const res = await PrintApi.getPrinterTypes()
    this.printerTypesData = res.data
    return this.printerTypesData
  }

  registerHandler(name: string, handler: Function) {  // 注册回调供原生调用
    // ...
  }
}

Provider 组合（src/pages/CommissionScreen.tsx）：

<ADProvider>                    {/* UI 组件库主题 */}
  <SafeAreaProvider>            {/* 安全区域 */}
    <SLHProvider value={{       {/* 业务配置 */}
      appName, locale, fontScaleLevel,
      dev: isTest ? 'dev' : 'prod',
      dllog, theme
    }}>
      <CommissionView />
    </SLHProvider>
  </SafeAreaProvider>
</ADProvider>

和 Redux 的对比

三层对比

❌ 初级做法：所有状态用 useState 堆在组件里
   → 状态散落各处，无法跨组件共享，逻辑和 UI 耦合

⚠️ 中级做法：无论项目大小都上 Redux
   → 小项目过度设计，Hybrid 项目中大部分状态在原生侧管理不到

✅ 资深做法：根据项目类型选择状态方案
   → Hybrid App：Service 单例 + Provider（原生管核心状态，RN 管 UI 配置）
   → 纯 RN App + 复杂状态：Redux/Zustand
   → 关键判断：状态的"主人"在哪？在原生就别在 RN 再管一份

面试话术

面试话术："这个项目的状态管理没有用 Redux，而是 Service 单例 + React Context。原因是它是 Hybrid 架构，核心状态（用户信息、环境配置、登录态）由原生管理，通过 NativeModules 传给 RN；RN 侧只需要管 UI 配置和局部业务状态。Service 单例负责有生命周期的业务逻辑（比如打印队列），Provider 负责分发不变的配置。这比 Redux 轻得多，也更贴合 Hybrid 的职责分工。"

质量思维：Service 单例的测试性挑战

单例模式最大的代价是测试困难，资深工程师必须知道怎么破局：

// ❌ 难以测试的单例
class PrintSvc {
  private static instance: PrintSvc
  private printerList: any[] = []

  static getInstance() {
    if (!this.instance) this.instance = new PrintSvc()
    return this.instance
  }

  async loadPrinters() {
    const res = await fetch('/api/printers')  // 直接依赖外部
    this.printerList = res.data
  }
}

// 测试问题：
// 1. 单例跨测试用例共享 state → 测试之间互相污染
// 2. fetch 硬编码 → 没法 mock
// 3. private 字段 → 测试里读不到验证状态

三层演进：

// ❌ 初级：直接用单例，测试 hack 式清理
beforeEach(() => {
  (PrintSvc as any).instance = null  // 反射破坏封装
  jest.clearAllMocks()
})

// ⚠️ 中级：加一个 reset 方法
class PrintSvc {
  static reset() { this.instance = null }
}
beforeEach(() => PrintSvc.reset())
// 问题：测试专用 API 污染生产代码

// ✅ 资深：依赖注入 + 接口抽象
interface PrintApi {
  getPrinters(): Promise<Printer[]>
}

class PrintSvc {
  constructor(private api: PrintApi) {}
  async loadPrinters() { 
    this.printerList = await this.api.getPrinters() 
  }
}

// 生产代码
const svc = new PrintSvc(realPrintApi)

// 测试代码
const mockApi = { getPrinters: jest.fn().mockResolvedValue([...]) }
const svc = new PrintSvc(mockApi)  // 每个测试独立实例

本项目的实际策略：生产代码用单例（方便调用），内部依赖通过 registerHandler 注入（方便 mock）。这是"默认单例，需要时注入"的折中方案。

思考题讨论

Q1：单例 + Context 的边界在哪？什么该放单例，什么该放 Context？

用户回答：不清楚两者的职责分工。

正确解答：

心智模型：存储位置 vs 访问方式

Service 单例：
  存储位置：模块作用域（全局）
  访问方式：直接 import 调用
  生命周期：随 App 进程
  
  → 适合：业务逻辑 + 有生命周期的状态
     - 打印队列、MQTT 连接、用户行为追踪
     - 状态对象"属于业务"，不属于某个 UI 组件

Context Provider：
  存储位置：React 树（组件作用域）
  访问方式：useContext hook
  生命周期：随组件挂载
  
  → 适合：配置 + 主题 + 需要响应式更新的数据
     - 语言、主题、当前用户权限
     - 状态"属于 UI 树"，组件 unmount 后不需要

反模式对照：

❌ 把 UI 主题放单例里
  class ThemeSvc { currentTheme = 'light' }
  → 换主题时组件不会重渲染（脱离 React）
  → 必须手动 forceUpdate，违背 React 心智模型

❌ 把 MQTT 连接放 Context 里
  <MqttContext.Provider value={mqttClient}>
  → Provider 所在组件 unmount → mqtt 重连
  → 跨页面保持连接的需求没法满足

本项目的划分（src/pages/CommissionScreen.tsx）：

<ADProvider>           {/* UI 库主题 - Context，响应式切换 */}
  <SLHProvider>        {/* 业务配置 - Context，响应式更新 */}
    <CommissionView /> {/* 业务组件里用 PrintSvc.getInstance() - 单例 */}
  </SLHProvider>
</ADProvider>

Q2：多个 RN 页面共享 Bridge 时，单例的状态怎么隔离？

正确解答：

这是共享 Bridge 架构下的真实痛点：

场景：
  页面 A 打开 → PrintSvc.loadPrinters() → 打印机列表 = [A1, A2]
  关闭 A，打开 B → B 应该看到属于它的打印机列表
  但 Singleton 状态还在 → B 看到的是 [A1, A2]

三种解法：

方案 1：页面卸载时手动 reset
  componentWillUnmount() { PrintSvc.getInstance().reset() }
  → 简单，但容易漏
  → 如果页面 crash unmount 没触发，脏数据残留

方案 2：作用域单例（按页面 key 分配实例）
  PrintSvc.forPage('A')  // 不同 key 返回不同实例
  → 实现复杂，需要跟踪 key 生命周期

方案 3：按数据"所有权"决策
  真正全局的（MQTT 连接、设备信息）用单例
  页面级的（当前选中打印机、打印队列）用 useState
  → 最清晰，本项目的实际做法

**识别"谁是数据的主人"**是资深设计能力：

判断 checklist：
  □ 这个数据在 App 全生命周期都有意义吗？
    Yes → 单例
    No（只在某个页面有意义）→ 组件 state 或 Context

  □ 多个页面都会访问并修改吗？
    Yes → 单例 + 事件通知
    No（只有一个页面用）→ 组件 state

  □ 原生侧是否也需要访问？
    Yes → 原生管理，RN 通过 Bridge 读
    No → RN 纯 JS 管理

Q3：Service 单例 + 并发调用会有问题吗？

用户回答：不清楚 JS 单线程下的"伪并发"。

正确解答：

JS 是单线程没错，但 async/await 的交错执行 会制造伪并发 bug：

class PrintSvc {
  private printerList: Printer[] = []
  private loading = false

  async loadPrinters() {
    if (this.loading) return this.printerList
    this.loading = true
    const res = await fetch('/api/printers')  // ← 这里让出线程
    this.printerList = res.data
    this.loading = false
  }
}

// 并发调用：
Promise.all([
  PrintSvc.loadPrinters(),  // 启动
  PrintSvc.loadPrinters(),  // loading=true，return printerList（但还没 fetch 完！）
])
// 第二个调用返回空数组

正确的并发防护：

class PrintSvc {
  private loadPromise: Promise<Printer[]> | null = null

  async loadPrinters() {
    if (this.loadPromise) return this.loadPromise  // 复用进行中的 Promise
    this.loadPromise = fetch('/api/printers')
      .then(res => { this.printerList = res.data; return res.data })
      .finally(() => { this.loadPromise = null })
    return this.loadPromise
  }
}

这个模式叫 "Promise Memoization"，是并发去重的标准方案。适用场景：

• 接口 debounce（页面多组件同时发同一请求）
• 初始化逻辑（避免重复 init）
• 资源获取（比如同时请求一个 token）

面试话术："单例在 JS 里看起来简单，但 async/await 会制造并发陷阱。我在 PrintSvc 里踩过一个坑：两个组件同时调 loadPrinters，flag 只在第一次生效，第二次直接返回空数组。修复用 Promise Memoization——把 inflight 的 Promise 缓存起来复用，天然去重。这让我认识到 JS 的'单线程'是指 JS 执行是单线程的，但 async 边界上多个 promise 交错调度，共享可变状态的代码依然会有'伪并发'问题。"

9. 业务插件系统与模块化架构

一句话结论

业务功能以独立 npm 包的形式存在，通过 biz-plugin/config.js 配置分支，postinstall 脚本自动下载——实现了多团队并行开发、独立版本控制、按需集成。

原理 / 本质

src/biz-plugin/config.js
   │
   │  配置: slhComponentBranch: 'master'
   ▼
postinstall 脚本
   │
   │  从 GitLab 下载对应分支的组件包
   ▼
node_modules/@ecool/slh-component   ← 主组件库
node_modules/@ecool/slh-commission  ← 佣金报表模块
node_modules/@ecool/slh-wms-modules ← 仓储模块
node_modules/@ecool/slh-ai          ← AI 功能模块
node_modules/@ecool/slh-ai-purchase ← AI 采购模块

每个模块暴露的接口：

// 模块导出路由（页面组件）
const routes = Commission?.getRoutes()
const CommissionView = routes[0]?.component

// 模块导出 Provider（配置注入）
import { SLHProvider } from '@ecool/slh-component'

为什么用这种方式而不是 Monorepo

相关代码位置

• 插件配置：src/biz-plugin/config.js:1-4
• 下载脚本：script/postinstall/slhComponent.js
• 使用示例：src/pages/CommissionScreen.tsx:29-30（动态获取路由组件）

面试话术

面试话术："我们的 App 把业务模块拆成独立的 npm 包，各团队独立开发、独立发版。主 App 通过 postinstall 脚本自动从 GitLab 下载对应分支的模块包。每个模块暴露路由组件和 Provider。这种架构的好处是：团队之间互不阻塞，模块可以独立回滚，主 App 只需要改分支配置就能切版本。本地开发时通过 config.js 配 localPath 指向本地目录，实现实时调试。"

设计模式识别：这是"微前端"思想在 RN 的落地

微前端（Micro Frontend）的核心理念搬到移动端：

Web 微前端：
  主应用（shell）
    ├─ 加载 React 团队的模块 http://react.example.com/bundle.js
    ├─ 加载 Vue 团队的模块 http://vue.example.com/bundle.js
    └─ 通过 iframe 或 Module Federation 集成
  
本项目的 RN "微模块"：
  主 App（RCTBridge）
    ├─ 加载 @ecool/slh-commission（佣金团队）
    ├─ 加载 @ecool/slh-wms-modules（仓储团队）
    └─ 加载 @ecool/slh-ai（AI 团队）
    
  每个模块独立仓库、独立部署、独立发版

共性：技术上分模块，组织上对齐 Conway's Law（康威定律）——"系统架构反映组织结构"。5 个业务团队 → 5 个 npm 包，团队分工和代码边界对齐。

三层对比

❌ 初级做法：所有业务代码都在主仓库
   → 冲突多、发布慢、一个团队改动影响所有人
   → 大仓库 100 万行代码，新人入职一周才能跑起来

⚠️ 中级做法：Monorepo（Turborepo / Nx）
   → 解决了部分组织问题，但所有代码还在一个仓库
   → 需要配复杂的构建工具，学习曲线陡
   → 权限难细分（所有人都能看所有代码）

✅ 资深做法（本项目）：独立仓库 + 构建时集成
   → 各团队完全隔离仓库 → 权限、CI、版本独立
   → 通过分支名灵活切换集成版本
   → 本地开发用 localPath 切到本地仓库实时调试
   → 线上线下、主线/分支、生产/测试 全部通过配置切换

为什么不用 npm registry？

理论最优方案：发布到 npm private registry
  package.json:
    "@ecool/slh-component": "^2.3.0"
  
实际选择：从 GitLab 动态下载
  config.js:
    slhComponentBranch: 'master'
  postinstall: 下载对应分支 zip

为什么选第二种？
  1. 迭代速度需求
     - 业务团队经常临时发分支版本测试
     - npm 每次都要 publish，有版本号心智负担
     - Git 分支天然就是版本，改个字符串就切换
  
  2. 权限管理简单
     - 公司已有 GitLab 权限体系
     - 不用额外搭建 private npm registry
  
  3. 灵活的版本策略
     - 生产用 master 分支
     - 测试用 feature/xxx 分支
     - 一键切换，不需要改 package.json

代价：
  1. 没有语义化版本（semver）约束
  2. 没有 npm 的 integrity 校验
  3. 依赖 GitLab 可用性

这是典型的"便利性 vs 规范性"权衡，中小团队选便利性，大公司通常演进到 private registry + semver。

安全思维：构建时集成的供应链风险

攻击面：

1. GitLab 仓库被入侵
   └─ 攻击者推恶意代码到 master → 下次 yarn install 自动拉取 → 集成到主 App
   → 防御：仓库 protect master 分支 + 强制 MR review

2. postinstall 下载 zip 被中间人篡改
   └─ HTTPS 理论上防御，但内网 CA 或 proxy 可能被入侵
   → 防御：加 SHA 校验（前面 Ch 3 讨论过）

3. 业务模块的 dependencies 失控
   └─ @ecool/slh-component 引入了某个被污染的 npm 包
   └─ 主 App 看不到、审计不到这个间接依赖
   → 防御：定期 npm audit + SCA（Software Composition Analysis）工具

对比 npm registry 方式：npm 至少有 integrity 字段、有 audit 机制、有社区漏洞数据库。构建时从 Git 下载绕过了这层防护。

思考题讨论

Q1：本地开发时的 localPath 是怎么工作的？

用户回答：不清楚 localPath 的机制。

正确解答：

// src/biz-plugin/config.js
module.exports = {
  slhComponent: {
    branch: 'master',
    localPath: '/Users/xxx/ecool/slh-component',  // 本地仓库路径
  }
}

// script/postinstall/slhComponent.js 的逻辑
if (config.localPath && fs.existsSync(config.localPath)) {
  // 本地模式：复制本地目录到 node_modules
  copyDir(config.localPath, 'node_modules/@ecool/slh-component')
} else {
  // 远程模式：从 GitLab 下载
  downloadFromGitLab(config.branch)
}

和 npm link 的区别：

npm link：
  node_modules/@ecool/slh-component → symbolic link → /Users/xxx/ecool/slh-component
  ├─ 改本地文件 → 主 App 立刻看到变化（真正的实时）
  └─ 问题：symlink 在 Metro 的 watch 机制下经常出坑

postinstall copyDir：
  node_modules/@ecool/slh-component 是本地目录的完整副本
  ├─ 改本地文件 → 需要重新 yarn install 同步
  └─ 优势：Metro 看到的就是真文件，没有 symlink 坑

Metro 特殊性：
  Metro 的 Haste map 索引 node_modules 假设是扁平的真目录
  symlink 会导致模块解析不稳定、watchman 不工作
  所以 RN 社区普遍用 copy 而不是 link

Q2：如果某个业务模块想用主 App 没有的依赖怎么办？

正确解答：

这是插件化架构的永恒难题——依赖冲突。

场景：
  主 App package.json: "react-native-chart-kit": "1.0.0"
  @ecool/slh-commission 需要: "react-native-chart-kit": "2.0.0"
  
  yarn install 后 node_modules 只能有一份 react-native-chart-kit
  版本不一致 → 要么业务模块挂，要么主 App 挂

三种常见解法：

方案 A：对齐版本
  业务模块迁就主 App 的版本 → 必要时降级
  → 协作成本高，但架构简单

方案 B：peerDependencies
  业务模块声明 peerDependency: "react-native-chart-kit": ">=1.0.0"
  主 App 负责安装
  → 标准做法，但要求主 App 知道所有子模块的依赖

方案 C：模块内嵌依赖
  业务模块把依赖编进自己的 bundle
  → 体积翻倍，不推荐

方案 D：原生模块分离
  纯 JS 依赖可以各自带一份（稍微浪费）
  有原生代码的依赖必须对齐（否则 iOS link 失败）

本项目的实际处理：靠团队沟通 + 定期整理 peer dependencies。没有技术层面的强制隔离，规模扩大后会成为痛点。

Q3：为什么不直接 npm publish 到 npm 官方？

核心原因：私密性。

业务模块里通常有：
  - 公司业务逻辑（商业机密）
  - 内部 API 地址
  - 安全敏感的代码（支付、认证）

发到 npm 官方 = 向全世界开源
→ 不符合企业需求

所以企业有三种选择：
  1. 自建 private registry（Verdaccio、Nexus、Artifactory）
     → 成本高但最规范
  2. 使用托管服务（npm Enterprise、GitHub Packages）
     → 付费但省心
  3. 直接从 Git 下载（本项目方案）
     → 免费但牺牲部分规范性

中小企业典型演进：

阶段 1（人少）：代码全放主仓库
阶段 2（模块化需求）：从 Git 下载（本项目在这个阶段）
阶段 3（规模化）：自建 private registry
阶段 4（大厂）：Monorepo + 内部 Bazel/Buck 构建系统

面试话术："我们用的不是传统 npm 依赖，而是 postinstall 从 GitLab 按分支名动态下载业务模块。这种设计的好处是业务团队不用关心 npm 发版流程，改完推 master 主 App 下次安装就能拿到；坏处是绕过了 npm 的 integrity 校验和 semver 约束，供应链安全需要靠 GitLab 仓库保护和 MR 流程来补足。本质上这是把'微前端'的思想搬到移动端——用独立仓库对齐独立团队，用构建时集成串起来。规模再大一步就应该演进到 private npm registry，但对当前团队规模（5 个业务团队）这个方案是 ROI 最高的。"

10. 企业级打印系统：蓝牙 + MQTT 双通道架构

一句话结论

打印系统支持两种通道——本地蓝牙直连和云端 MQTT 下发，运行时根据配置切换，实现了从"一台打印机"到"多门店多打印机"的扩展能力。

架构图

            用户点击"打印"
                 │
                 ▼
          ┌─────────────┐
          │  PrintSvc    │  ← RN 端打印服务（999行）
          │  (TypeScript) │
          └──────┬───────┘
                 │
        ┌────────┴────────┐
        ▼                  ▼
  通道 A：蓝牙直连      通道 B：MQTT 云端
  ┌──────────────┐    ┌──────────────┐
  │ YKBLEPrintSvc│    │  MqttSvc     │
  │  (ObjC)      │    │  (TypeScript) │
  │              │    │              │
  │ CoreBluetooth│    │ MQTT Broker  │
  │ ESC/POS 指令 │    │ → 云端打印机  │
  └──────┬───────┘    └──────┬───────┘
         │                    │
         ▼                    ▼
   本地蓝牙打印机         远程网络打印机
   （收银台旁边）         （仓库/门店）

关键设计

1. Handler 注册表模式（src/svc/PrintSvc.ts:442-691）：

// 注册处理函数，供原生侧通过 Bridge 调用
registerHandler('initMqttSvc', async (data?, cb?) => {
    MqttSvc.getInstance().init(productInfo, {
        uploadLogFile: () => { ... },
        disConnectPrinter: () => { ... },
        printByData: (data) => { ... },
        onMqttConnect: () => { ... },
    })
})

registerHandler('printByData', async (data?, cb?) => {
    // 根据当前通道路由到蓝牙或 MQTT
})

2. 运行时通道切换（ios/Print/Svc/YKBLEPrintSvc.m）：

if (g_print_user_new_service == 2) {
    // 云端 MQTT 打印
    ReactNativeBridge *jsBridge = [bridge moduleForName:@"ReactNativeBridge"];
    [jsBridge callHandler:@"printByData" data:printData responseCallback:nil];
} else {
    // 本地蓝牙打印
    [self printWithBLEPrinter:printData];
}

3. XML 模板解析：打印内容用 XML 定义，按 </main> 标签分页，支持多联打印（小票 + 标签 + 发票）。

为什么值得学习

这个打印系统体现了资深架构师的思维：

1. 策略模式：蓝牙和 MQTT 是两个打印策略，通过配置切换，调用方无需关心底层实现
2. 渐进式迁移：从蓝牙到 MQTT 不是一刀切，而是两套共存、逐步迁移
3. 跨层协作：RN（TypeScript） → Native Module（ObjC） → 硬件（蓝牙/网络），三层配合

三层对比

❌ 初级做法：打印逻辑硬编码在页面组件里
   → 换打印机类型要改每个页面

⚠️ 中级做法：抽出 PrintService，但只支持一种打印方式
   → 新增云端打印需要大量重构

✅ 资深做法：策略模式 + Handler 注册表
   → 新增打印通道只需注册新 handler
   → 运行时切换无需改代码
   → 原生和 RN 通过 Bridge 解耦，各自独立演进

面试话术

面试话术："我们的打印系统支持蓝牙直连和 MQTT 云端两种通道，用策略模式实现运行时切换。RN 端的 PrintSvc 通过 registerHandler 注册打印处理函数，原生端根据配置决定走蓝牙还是 MQTT。蓝牙打印走 CoreBluetooth + ESC/POS 指令，MQTT 打印走 RN 的 MqttSvc 下发到云端打印机。这种架构的好处是新增打印通道只需注册新 handler，不需要改已有代码。实际落地时我们是两套并存、逐步迁移，没有一刀切。"

延伸讨论

Q: 蓝牙打印的坑在哪？

• 数据包大小限制（MTU 通常 20-512 字节），大票据需要分包发送
• 打印机响应慢时需要流控（发太快会丢数据）
• iOS 后台限制蓝牙连接，App 切后台可能断连
• 不同品牌打印机的 ESC/POS 指令有差异

Q: 为什么选 MQTT 而不是 WebSocket？

• MQTT 是为物联网设计的，自带 QoS（消息保证投递）、遗嘱消息（设备掉线通知）、主题订阅
• 打印机场景天然是"多对多"（多门店 → 多打印机），MQTT 的 pub/sub 模型完美匹配
• WebSocket 更适合"一对一"的实时通信

思考题讨论

Q1：为什么共享一个 Bridge 而不是每个 RN 页面创建自己的？

用户回答：不清楚 Bridge 的初始化机制和内存成本。

暴露的知识盲区：对 RCTBridge 的底层机制没有认知——不知道它初始化时做了什么、占用多少资源。

正确解答：

Bridge 初始化时做了 4 件重量级操作：

RCTBridge 创建
    │
    ├── 1. 启动 JS 引擎（JavaScriptCore/Hermes）   ← ~100-200ms
    ├── 2. 加载 JS Bundle（所有 RN 代码）            ← ~200-500ms
    ├── 3. 注册所有 NativeModules                    ← 遍历所有原生模块
    └── 4. 建立 Native ↔ JS 的消息队列               ← 双向通信通道

每个 Bridge 占用一个 JS 引擎实例（几十 MB 内存）+ 一份完整 JS Bundle 副本。如果每个页面创建独立 Bridge，3 个页面就要 150MB + 每次打开卡 400ms。共享一个 Bridge 则是 50MB + 一次性启动，后续页面瞬间打开。

三层对比：

❌ 初级做法：每个页面 new 一个 Bridge
   → 内存爆炸 + 打开卡顿，用户体验极差

⚠️ 中级做法：知道共享 Bridge，但不理解为什么
   → 无法在面试中解释底层原因

✅ 资深做法：理解 Bridge 的初始化成本，选择共享模式
   → 类比：不会为每个 Tab 页启动一个新浏览器进程

面试话术："RCTBridge 初始化需要启动 JS 引擎、加载 Bundle、注册所有原生模块，大约 400ms 且占几十 MB 内存。所以我们在 AppDelegate 中只创建一个 Bridge，所有 RN 页面通过 RCTRootView 复用这个 Bridge。这样后续打开 RN 页面几乎零成本，类似浏览器多个 Tab 共享一个进程。"

Q2：从零设计打印系统，先做蓝牙还是 MQTT？

用户回答：不清楚如何做技术选型的优先级判断。

暴露的知识盲区：缺少 MVP 思维和 ROI（Return On Investment，投资回报率）意识——不知道怎么判断"先做什么"。

正确解答：先蓝牙。

核心判断依据是 MVP 原则 + ROI 分析：

先做蓝牙的理由：

1. 覆盖核心场景：80% 用户就是站在打印机旁边打印小票
2. 零依赖：不需要服务器、不需要网络，CoreBluetooth + ESC/POS 指令就够了
3. 快速交付：一周出 MVP，用户立刻能用
4. 可扩展：后续加 MQTT 通道用策略模式切换，不改蓝牙代码

先做 MQTT 的问题：

1. 需要先搭服务端基础设施（1 个月+）
2. 依赖网络，断网就打印不了（连基础场景都不可用）
3. 过度设计——为 20% 场景投入 80% 的开发时间

本项目的实际演进就是这条路径：先蓝牙 → 再加 MQTT → g_print_user_new_service 运行时切换。

通用决策框架：

技术选型问题 → 先问三个问题：

1. 核心用户场景是什么？（80/20 法则找最高频场景）
2. 最小可用方案是什么？（能满足核心场景的最简实现）
3. 后续能不能扩展？（不是现在做，而是架构上留口子）

→ 先做 ROI 最高的（低成本 + 高覆盖）
→ 再做 ROI 次高的（高成本但有增量价值）

ROI 全称：Return On Investment（投资回报率）。技术语境下 = "花多少精力、得多少收益"。资深工程师做决策不是选"技术上最酷的"，而是选"当前阶段 ROI 最高的"。

面试话术："技术选型我会用 ROI 框架。比如打印系统，蓝牙直连 1 周覆盖 80% 场景且零依赖，MQTT 要 1 个月且依赖服务端只覆盖 20%——所以先做蓝牙。但架构上用策略模式预留扩展点，后续加 MQTT 只需注册新 handler，不改已有代码。这就是 MVP 思维——先用最低成本验证核心场景，再逐步扩展。"

11. JS 引擎与 JS Bundle：RN 代码如何在手机上运行

一句话结论

JS 引擎是把你的 JS 代码翻译成 CPU 指令的"翻译官"，JS Bundle 是 Metro 把几百个源文件打包成的单个文件。两者配合完成"开发时写的代码 → 手机上跑起来"的全过程。

为什么需要了解这个

不理解 JS 引擎和 Bundle，就无法理解 RN 的启动性能瓶颈、热更新原理、Debug/Release 模式差异。这是 RN 开发者必须掌握的底层认知。

JS 引擎：翻译官

手机 CPU 看不懂 JavaScript，需要 JS 引擎把 JS 代码翻译成机器指令。不同环境用不同引擎：

JavaScriptCore vs Hermes

JSC（本项目使用）——运行时编译：

App 启动
    │
    ▼
加载 JS Bundle（JS 源码文本，2-5MB）
    │
    ▼
JSC 解析源码 → 生成 AST → 编译为字节码 → 执行
    │
    └── 每次启动都重新做，在用户手机上实时编译

Hermes——提前编译（AOT, Ahead-Of-Time）：

打包时（你的电脑上）
    │
    ▼
JS Bundle → Hermes 编译器 → 字节码文件（.hbc）
    │
    └── 编译只做一次，在开发者电脑上完成

App 启动
    │
    ▼
直接加载字节码 → 立即执行
    │
    └── 跳过"解析+编译"，所以更快

核心区别：

JS Bundle：打包产物

你写的几百个 .ts/.tsx 文件不可能一个个加载到手机上。Metro bundler（RN 的 Webpack）把它们打包成一个文件：

源码（几百个文件）                    JS Bundle（一个文件）
├── src/App.tsx                      
├── src/pages/PrintTaskScreen.tsx     
├── src/pages/ScanScreen.tsx         Metro Bundler
├── src/svc/PrintSvc.ts            ────────────▶  main.jsbundle
├── src/components/Table/index.tsx                 （2-5MB）
├── node_modules/react/...           
└── ... 

与前端的对比：

前端 Web：  src/*.tsx → Webpack → dist/bundle.js → 浏览器下载执行
React Native：src/*.tsx → Metro → main.jsbundle → App 启动时加载执行

Bundle 在 App 中的位置

slh_new.app（安装到手机上的包）
    ├── 原生二进制（ObjC 编译后的机器码）
    ├── main.jsbundle          ← JS Bundle
    ├── assets/                ← 图片资源
    └── Frameworks/            ← Charts.framework 等

开发模式 vs 生产模式

开发模式（Debug）：
  Metro Dev Server 跑在你的电脑上
  手机通过局域网实时拉取 Bundle
  → 改代码秒刷新（Hot Reload），但启动慢、性能差

生产模式（Release）：
  Metro 提前打包 main.jsbundle，内嵌进 App 包
  手机从本地文件加载
  → 不能热刷新，但启动快、性能好

CodePush 热更新的原理

传统发版：                          CodePush 热更新：
改 JS 代码                         改 JS 代码
    ↓                                  ↓
重新打包 .ipa                       重新打包 main.jsbundle
    ↓                                  ↓
提交 App Store 审核（1-3 天）         上传到 CodePush 服务器
    ↓                                  ↓
用户手动更新 App                     App 启动时自动下载新 Bundle
                                       ↓
                                    替换本地的 main.jsbundle
                                       ↓
                                    下次启动生效（秒级更新）

这就是 RN 相比纯原生的核心优势：JS 代码是动态加载的文件，不是编译进二进制的。替换这个文件就等于更新了 App 的全部 JS 逻辑，无需经过 App Store 审核。

限制：CodePush 只能更新 JS Bundle。如果改了原生代码（ObjC/Swift/Podfile），就必须走 App Store 发版。

本项目的配置

ios/Podfile:18：

:hermes_enabled => false   # 关闭 Hermes，使用 JSC

原因：RN 0.66 时期 Hermes 在 iOS 上不够成熟，存在兼容问题。RN 0.70+ 后 Hermes 成为默认引擎。

.gitlab-ci.yml:25-31 中配置了 CodePush，说明本项目使用热更新机制。

三层对比

❌ 初级做法：不知道 JS Bundle 是什么，以为 RN 代码直接跑在手机上
   → 无法理解启动慢、Debug 和 Release 行为不同的原因

⚠️ 中级做法：知道有 Bundle 和 JS 引擎，但不理解 JSC 和 Hermes 的区别
   → 无法解释为什么 Hermes 更快，面试时答不出 AOT 的原理

✅ 资深做法：理解完整链路（源码 → Metro 打包 → Bundle → 引擎加载 → 执行）
   → 能分析启动性能瓶颈在哪
   → 能解释 CodePush 为什么能绕过 App Store
   → 能判断什么时候该开 Hermes（RN 0.70+必开）

面试话术

面试话术："RN 的代码执行链路是：Metro 把 TS/JS 源码打包成一个 main.jsbundle 文件，内嵌在 App 包里。App 启动时，RCTBridge 创建 JS 引擎加载这个 Bundle。老版本 RN 用 JavaScriptCore，每次启动都要实时解析编译，比较慢；新版本用 Hermes，在打包时就预编译成字节码，启动时直接执行，内存降低 40%、首屏快一倍。我们还用了 CodePush 做热更新，本质就是替换 App 里的 jsbundle 文件，不需要走 App Store 审核。"

延伸讨论

Q: 为什么 Debug 模式比 Release 慢很多？

• Debug 模式下 Bundle 从 Metro Dev Server 通过网络拉取（vs Release 从本地文件读取）
• Debug 模式不做代码压缩和 tree-shaking，Bundle 体积大几倍
• Debug 模式开启了各种开发工具（Inspector、Hot Reload），额外开销大

Q: Hermes 有什么缺点？

• 不支持 JIT（Just-In-Time 编译），长时间运行的计算密集型任务可能比 JSC 慢
• 早期版本对某些 JS 特性支持不完整（如 Proxy、Intl）
• 但对 RN App 来说，启动速度和内存占用比 JIT 性能更重要，因为 UI 渲染是原生做的

12. MQTT 协议：为什么打印系统不用 HTTP/WebSocket

一句话结论

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议）是专为物联网设计的发布/订阅协议。打印机是典型的 IoT 设备——数量多、网络不稳定、需要可靠投递——所以用 MQTT 而不是 HTTP/WebSocket。

用前端知识理解

// 前端 EventEmitter（只在一个进程内有效）
emitter.on('order/print', callback)      // 订阅
emitter.emit('order/print', data)        // 发布

// MQTT（跨设备、跨网络的 EventEmitter）
mqttClient.subscribe('shop/101/print')   // 打印机订阅主题
mqttClient.publish('shop/101/print', data) // App 发布打印任务

MQTT 本质就是一个跨设备、跨网络的全局 EventEmitter。

三个角色

Publisher（发布者）        Broker（中间人）          Subscriber（订阅者）
   店员 App               MQTT 服务器               打印机们
    │                        │                        │
    │  publish 到            │  按"主题"路由到          │
    │  "shop/101/print"  ──▶│  所有订阅者          ──▶│ 仓库打印机
    │                        │                     ──▶│ 前台打印机
    │                        │                     ──▶│ 标签打印机

对比 WebSocket：

WebSocket：客户端 ←──直连──→ 服务端（一对一）
MQTT：    客户端 ──→ Broker ──→ 多个客户端（多对多，按主题分发）

为什么打印场景用 MQTT

QoS（Quality of Service，服务质量等级）

MQTT 最核心的特性——保证消息投递：

QoS 0：最多一次（发了不管，可能丢）    → 温度上报等不重要数据
QoS 1：至少一次（确保到达，可能重复）   → 打印任务（重复打印比丢单好）
QoS 2：恰好一次（不丢不重）           → 支付等关键场景，但最慢

本项目打印用 QoS 1——宁可多打一张也不能漏单。

本项目中的使用

店员点击"打印"
    │
    ▼
PrintSvc (RN) → MqttSvc.publish('打印任务')
    │
    ▼
MQTT Broker（云端服务器）
    │
    ▼
仓库打印机（subscribe 了对应主题）→ 收到任务 → 打印

相关代码：src/svc/PrintSvc.ts:468-576（MqttSvc 初始化和消息处理）

面试话术

面试话术："我们的云端打印用 MQTT 协议。选 MQTT 而不是 WebSocket 有三个原因：一是打印场景天然是一对多（一个订单可能触发多台打印机），MQTT 的发布/订阅模型完美匹配；二是打印机网络不稳定，MQTT 的 QoS 1 保证消息至少投递一次，不会丢单；三是 MQTT 有遗嘱消息机制，打印机掉线时 Broker 自动通知管理端。这些能力 WebSocket 都要自己实现。"

三层对比

❌ 初级做法：HTTP 轮询
   前端每 5 秒问一次"有新任务吗"
   → 延迟高、服务器压力大、费电

⚠️ 中级做法：WebSocket 直连
   客户端 ↔ 服务器长连接，服务器主动推送
   → 解决了推送问题，但要自己实现：
     - 断线重连
     - 消息可靠投递（ACK 机制）
     - 一对多分发（自己管理连接池）
     - 离线消息缓存

✅ 资深做法：MQTT
   Broker 中间件帮你解决一切：
     - QoS 投递保证
     - 发布订阅模型
     - 遗嘱消息（会话状态）
     - 主题过滤（层级路由）
     - 保留消息（retained message）
   → 用现成的标准协议，不重复造轮子

系统思维：主题（Topic）的分级设计

MQTT 的主题采用层级结构，好的设计决定系统的可扩展性：

❌ 初级设计（扁平）：
  printer_1_task
  printer_2_task
  printer_3_task
  → 订阅者要订阅成百上千个主题
  → 加新打印机要改订阅逻辑

✅ 资深设计（层级）：
  shop/{shopId}/printer/{printerId}/task
  shop/{shopId}/printer/{printerId}/status
  shop/{shopId}/printer/+/status          ← 通配符：某店所有打印机状态
  shop/+/printer/+/status                 ← 所有店所有打印机
  shop/#                                   ← 某店所有东西
  
  通配符：
    +  单层通配
    #  多层通配（只能在末尾）
  
  → 订阅一次覆盖多个设备
  → 权限控制精细化（某门店店员只能订阅 shop/{他的店}/#）

本项目主题设计要点：

• 按"组织/设备/动作"三级划分
• 权限和主题结构对齐（门店级权限 = 订阅对应前缀的主题）

扩展性：Broker 的高可用

单机 Broker 的问题：

• Broker 宕机 → 所有打印系统瘫痪（单点故障）
• 消息吞吐受限于单机资源

资深方案：

阶段 1：单机
  所有打印机连同一个 Broker
  
阶段 2：主备
  主 Broker 挂 → 自动切备机
  → 断连期间消息延迟
  
阶段 3：集群（EMQX / HiveMQ / VerneMQ）
  多 Broker 节点 + 一致性哈希分发
  消息在节点间同步
  客户端连任意节点都能收到
  → 水平扩展，理论无上限

阶段 4：多区域
  华东集群 + 华南集群 + 海外集群
  全球 App 就近接入
  → 类似 CDN 的架构

企业级 MQTT Broker（EMQX）单集群可以支持千万级连接 + 百万级消息/秒。对比 WebSocket 自建，一个人能搞定的吞吐量天差地别。

思考题讨论

Q1：打印任务为什么选 QoS 1 而不是 QoS 2？

用户回答：不清楚 QoS 0/1/2 的实际代价。

正确解答：

QoS 0（最多一次）：
  client → broker: PUBLISH
  → 1 次消息，最简单
  → 网络抖动可能丢
  → 用于：温度/GPS 上报（丢一两次无所谓）

QoS 1（至少一次）：
  client → broker: PUBLISH
  broker → client: PUBACK
  → 2 次消息
  → 客户端未收到 PUBACK 会重发 → 可能重复投递
  → 用于：打印任务（宁可重复不可丢失）

QoS 2（恰好一次）：
  client → broker: PUBLISH
  broker → client: PUBREC
  client → broker: PUBREL
  broker → client: PUBCOMP
  → 4 次消息握手 + broker 要持久化去重表
  → 开销是 QoS 1 的 2 倍以上
  → 用于：支付、转账（绝对不能重复）

为什么打印任务用 QoS 1 而不是 QoS 2：

打印场景的业务特性：
  1. 打印机有物理显示，多打一张用户能发现（拿掉就行）
  2. 漏打非常麻烦（用户不知道少了什么）
  3. 服务质量：保证一定能打印 > 避免重复打印
  
结论：重复打印的代价 << 漏打的代价
     → QoS 1：宁可重复不能丢，性能也够用

反例（支付）：
  重复扣款的代价 >> 支付失败的代价
  → 必须用 QoS 2，或者在 QoS 1 基础上客户端自己做幂等 

工程原则：QoS 选型看业务语义的"重复代价"和"丢失代价"对比，不是无脑选最高等级。

Q2：遗嘱消息（Last Will）的本质是什么？怎么实现？

用户回答：不清楚遗嘱消息的机制。

正确解答：

问题背景：TCP 连接断开有两种情况：

优雅断开：客户端主动 disconnect → 服务端立即知道
非优雅断开：网线拔了、设备断电、App 崩了 → 服务端要等心跳超时（~60s）才知道

问题：等心跳的 60s 内，其他客户端不知道这个设备已经掉线
     → 继续发任务给它 → 任务石沉大海

MQTT 的解法：遗嘱消息

客户端连接时告诉 Broker：
  "我的遗嘱是：往 shop/101/printer/A/status 发 'offline'
   如果我非优雅断开，你帮我发这条消息"

Broker 心跳检测到客户端掉线：
  → 自动发布遗嘱消息
  → 订阅这个主题的其他客户端立即知道

实现原理：
  CONNECT 报文里包含 Will Topic + Will Message
  Broker 记住这个"遗嘱"
  发现连接异常断开时自动 publish

本项目应用：

打印机上线 → CONNECT + 遗嘱（"我掉线了"）
打印机掉线 → Broker 自动发 "offline" 到状态主题
管理 App 订阅了状态主题 → 立即看到打印机变灰

→ 不用自己实现心跳检测逻辑
→ 不用定期轮询打印机状态
→ 协议层原生支持

类比前端：就像 window.addEventListener('beforeunload', ...)——告诉浏览器"我关闭时帮我发个请求"。区别是 MQTT 遗嘱连"非优雅关闭"（断电、崩溃）都能触发，beforeunload 只能处理"优雅关闭"。

Q3：同样是推送，MQTT、WebSocket、SSE 怎么选？

完整对比：

选型框架：

需要双向 + 浏览器原生 → WebSocket
需要一对多 + 可靠投递 + 移动端 → MQTT
只要服务端推送 + 简单实现 → SSE（最轻量）

本项目如果换方案会怎样：

• 换 WebSocket：要自建连接管理、重连、QoS、遗嘱等 → 自建一个 MQTT 协议
• 换 SSE：无法双向通信（打印结果上报怎么做？）→ 要配合 HTTP POST 做上行，方案复杂化

面试话术："推送协议选型我会看三个维度：方向（单向/双向）、可靠性需求（是否需要消息保证）、扩展性（一对一 vs 一对多）。打印系统是双向+一对多+必须可靠，天然匹配 MQTT。如果只是股价推送这种单向场景，SSE 更轻量；如果是实时聊天这种单点双向，WebSocket 就够了。我踩过的坑是：早期有同事想用 WebSocket 替代 MQTT 省一个中间件，结果要自建消息重传、会话恢复、主题路由——最后代码量比直接用 MQTT 还多，稳定性还差。这让我认识到：选协议不是'能不能做到'，而是'做到要多少代码'——复用标准协议永远比自建便宜。"

13. RN 性能优化：为什么不分包 + 首屏优化手段全景

一句话结论

RN 不需要像 Web 那样分包（Code Splitting），因为 Bundle 从本地加载而非网络下载。RN 的首屏优化核心是减少 JS 引擎的解析执行时间，手段包括 Hermes AOT、Inline Requires、Bundle 瘦身、原生启动屏等。

为什么 Web 要分包而 RN 不需要

Web 的瓶颈 = 网络传输
  bundle.js（5MB）→ 用户通过网络下载 → 2-3 秒
  拆成 home.js（500KB）+ report.js（300KB）→ 先下载 500KB → 0.3 秒看到首页

RN 的瓶颈 = JS 引擎解析执行
  main.jsbundle（5MB）→ 内嵌在 App 包里，本地读取 → 10ms
  拆成 10 个小文件 → 本地读取还是 10ms，但多了 10 次 I/O
  → JS 引擎要处理的总代码量不变，不会更快

类比：

Web 分包 = 网购分批发货（物流慢，先发急需的）
RN 不分包 = 东西已经在你家里（不存在运输问题，瓶颈是拆箱整理）

RN 启动的完整流程（优化要看全链路）

用户点击 App 图标
    │
    ├── 阶段 1：原生初始化（~200ms）
    │   AppDelegate → 初始化第三方 SDK → 创建 RCTBridge
    │
    ├── 阶段 2：JS 引擎启动 + Bundle 加载（~300-800ms）⭐ 最大瓶颈
    │   创建 JS 引擎 → 加载 main.jsbundle → 解析 → 编译 → 执行
    │
    ├── 阶段 3：React 组件树渲染（~200-500ms）
    │   执行 App.tsx → 注册组件 → 初始化服务 → 首个组件 render
    │
    └── 阶段 4：原生 UI 渲染（~100ms）
        RN 布局指令 → Yoga 计算 → 原生 UIView 创建 → 上屏

总计首屏时间：~800ms - 2000ms

每个阶段的优化手段

阶段 1 优化：减少原生初始化时间

手段：延迟初始化第三方 SDK

❌ 错误做法：
  AppDelegate 启动时一口气初始化 Bugly + Sentry + GeTui + 微信 + 友盟
  → 全部同步执行，阻塞主线程 200ms+

✅ 正确做法：
  启动时只初始化必须的（crash 上报）
  其他 SDK 延迟到首屏显示后再初始化

本项目的情况（ios/slh_new/ThirdPart/YKThirdPartManager.m）：所有 SDK 在 didFinishLaunching 中同步初始化。可优化空间大。

阶段 2 优化：减少 JS 引擎解析执行时间 ⭐ 最重要

手段 A：开启 Hermes（AOT 编译）

JSC 模式：
  加载 JS 源码 → 解析 AST → 编译字节码 → 执行
  ──── 这三步每次启动都做 ────

Hermes 模式：
  加载预编译字节码 → 直接执行
  ── 跳过解析和编译，省 50%+ 时间 ──

本项目状态：ios/Podfile:18 → hermes_enabled => false（未开启）。这是最大的优化空间，但需要升级到 RN 0.70+ 才能稳定使用。

手段 B：Inline Requires（延迟 require）

// 普通 require —— App 启动时立刻执行所有 import
import HeavyModule from './HeavyModule'  // 启动就加载，即使这个页面还没打开

// Inline Require —— 真正用到时才执行
const HeavyModule = require('./HeavyModule')  // 延迟到调用时才加载

原理：普通 import 是静态的，Metro 打包后所有模块在 Bundle 加载时立刻执行。Inline Require 把 require() 调用推迟到运行时真正需要的时刻。

开启 Inline Requires 前：
  启动 → 执行 200 个模块 → 800ms → 首屏

开启 Inline Requires 后：
  启动 → 执行 30 个模块（首屏需要的）→ 200ms → 首屏
  用户点击报表 → 执行报表相关模块 → 按需加载

配置位置：metro.config.js:15 → inlineRequires: false（本项目未开启）

这是 RN 世界的"分包"——不是拆文件，而是延迟执行模块代码。

手段 C：RAM Bundles（随机访问模块 Bundle）

普通 Bundle：
  [模块A代码][模块B代码][模块C代码]...
  → JS 引擎从头到尾解析整个文件

RAM Bundle：
  [索引表: A→偏移量1, B→偏移量2, C→偏移量3]
  [模块A代码][模块B代码][模块C代码]...
  → JS 引擎只解析索引表，需要哪个模块才跳到对应位置读取

RAM Bundle 配合 Inline Requires 使用效果最好：索引表告诉引擎"模块在哪"，Inline Requires 决定"什么时候加载"。

注意：RAM Bundles 是 RN 实验性功能，Hermes 开启后不需要，因为 Hermes 字节码本身已经支持按需解析。

手段 D：Bundle 瘦身（减少总代码量）

本项目已有的优化（babel.config.js）：

['lodash'],                              // lodash tree-shaking
['import', { libraryName: '@ant-design/react-native' }],  // antd 按需引入
// production 环境：
['transform-remove-console']             // 去除 console

阶段 3 优化：减少 React 渲染时间

手段 E：减少启动时注册的组件数量

本项目的 src/App.tsx 启动时做了这些事：

// 1. 导入所有页面模块（~20个 import）
import PrintDeviceScreen from './pages/PrintDeviceScreen'
import CommissionScreen from 'pages/CommissionScreen'
// ... 20 个 import

// 2. 初始化服务
PrintSvc.setConfig()          // 同步执行
PrintSvc.registerHandler()    // 同步执行

// 3. 注册所有组件
AppRegistry.registerComponent('PrintDeviceScreen', () => PrintDeviceScreen)
// ... 20 个 registerComponent

// 4. 初始化网络
DLFetch.init()
DLFetch.setRequestConfig({...})

问题：20 个 import 在启动时全部执行，即使用户只打开了打印页面。

❌ 当前做法（所有 import 在顶部）：
  启动 → 加载 20 个页面模块 → 初始化服务 → 注册组件

✅ 优化做法（Inline Require + 懒注册）：
  启动 → 只注册入口 → 初始化必要服务
  用户打开某页面 → 才 require 该页面模块

手段 F：组件级优化

// 1. React.memo 避免不必要渲染
const ExpensiveList = React.memo(({ data }) => {
  return <FlatList data={data} renderItem={...} />
})

// 2. useMemo 缓存计算结果
const columns = useMemo(() => buildColumns(config), [config])

// 3. useCallback 缓存回调函数
const onPress = useCallback(() => handlePress(id), [id])

// 4. FlatList 优化配置
<FlatList
  data={data}
  keyExtractor={(item) => item.id}     // 稳定的 key
  windowSize={5}                        // 只渲染可见区域 ± 5 屏
  maxToRenderPerBatch={10}              // 每批渲染 10 个
  removeClippedSubviews={true}          // 移除不可见的子视图
  getItemLayout={(data, index) => ({    // 跳过布局计算
    length: ITEM_HEIGHT, offset: ITEM_HEIGHT * index, index
  })}
/>

// 5. 节流高频事件（本项目已有）
const onScan = _.throttle(handleScan, 2000)           // ScanScreen.tsx:32
const onCapture = _.throttle(handleCapture, 2000, { trailing: false })  // ShareDoucment.tsx:62

阶段 4 优化：原生启动屏（Splash Screen）

手段 G：用原生启动屏遮盖白屏

没有启动屏：
  点击图标 → 白屏 1-2 秒 → 首页出现（用户以为卡了）

有启动屏：
  点击图标 → 立刻显示 Launch Screen（原生，0ms）
           → JS 引擎在后台加载
           → 首页准备好了 → 隐藏 Launch Screen → 无缝过渡

启动屏是原生 LaunchScreen.storyboard，由 iOS 系统在 App 进程创建后立刻显示，不需要等 JS 引擎。这是所有 RN App 都应该有的基础优化。

优化手段总览与优先级

本项目的优化现状

三层对比

❌ 初级做法：不知道 RN 的性能瓶颈在哪
   → 照搬 Web 优化套路（分包、懒加载路由），对 RN 没效果

⚠️ 中级做法：知道 Hermes 快，但不理解为什么
   → 开了 Hermes 就觉得优化到位了，忽略了 Inline Requires 和 Bundle 瘦身

✅ 资深做法：从启动全链路分析瓶颈
   → 知道 4 个阶段各自的瓶颈和对应手段
   → 按 ROI 排优先级：Hermes > 启动屏 > Inline Requires > 其他
   → 能量化优化效果（用 react-native-performance 或 Flipper 测量）

面试话术

面试话术："RN 的首屏优化和 Web 不同——Web 的瓶颈是网络传输所以要分包，RN 的瓶颈是 JS 引擎解析执行所以要减少引擎工作量。我会从启动的 4 个阶段分析：原生初始化阶段延迟非必要 SDK；JS 加载阶段开启 Hermes 做 AOT 编译和 Inline Requires 延迟模块执行；React 渲染阶段用 memo/useMemo 减少重渲染；最后用原生启动屏消除白屏感知。其中 Hermes 的 ROI 最高——一行配置就能启动快 50%、内存降 40%。"

延伸讨论

Q: Inline Requires 和 Web 的动态 import() 有什么区别？

• Web 的 import() 会创建新的网络请求下载新 chunk 文件（真正的代码拆分）
• RN 的 Inline Requires 只是延迟执行 require()，代码还在同一个 Bundle 里
• 效果类似但机制不同：Web 是"不下载"，RN 是"不解析执行"

Q: 怎么量化首屏时间？

• react-native-performance 库：测量 JS Bundle 加载时间、首次渲染时间
• Flipper 的 Performance 插件：可视化每个阶段的耗时
• 原生端打点：在 didFinishLaunching 和 RCTBridge 回调中记录时间戳
• Systrace（Android）/ Instruments（iOS）：系统级性能分析

Q: 本项目最值得做的优化是什么？

• 开启 inlineRequires: true（metro.config.js:15 改一行），零风险，立即减少启动时加载的模块数
• 当前 App.tsx 顶部 20 个 import 在启动时全部执行，开启后只在真正用到时才执行

思考题讨论

Q1：inlineRequires 改成 true 后，App.tsx 顶部 20 个 import 行为怎么变？可能出什么问题？

用户回答：不理解 inlineRequires 的机制。

暴露的知识盲区：不清楚 import 在 RN Bundle 中的实际执行时机，以及 Metro 打包对 import 的转换行为。

正确解答：

inlineRequires: false（当前），Metro 打包后 import 变成立刻执行的 require：

// Bundle 加载时，20 个模块全部立刻执行
var PrintDeviceScreen = require('./pages/PrintDeviceScreen')   // 立刻
var CommissionScreen = require('pages/CommissionScreen')       // 立刻
var DeepSeekScreen = require('pages/DeepSeekScreen')           // 立刻
// ... 20 个全部立刻执行，每个模块又递归加载自己的依赖

inlineRequires: true 后，Metro 把 require 推迟到变量被使用的地方：

// 顶部不再有 require 调用

// 只有原生侧真正打开打印页面时，require 才执行：
AppRegistry.registerComponent('PrintDeviceScreen',
  () => require('./pages/PrintDeviceScreen'))

效果：启动时 JS 引擎从"加载 20 个页面模块及全部依赖"变成"只执行骨架代码"，工作量大幅减少。

可能出的问题：有些代码依赖"import 时的副作用"（side effect）。本项目 App.tsx 中有：

import 'reflect-metadata'        // 装饰器元数据，必须在启动时加载
PrintSvc.setConfig()              // 依赖前面的 import 已执行
PrintSvc.registerHandler()        // 同上
DLFetch.init()                    // 初始化网络

如果这些被延迟执行，后面的代码会读到未初始化的状态 → 崩溃。

解决方法：在 Metro 配置中排除有副作用的模块：

inlineRequires: {
  blockList: [
    'src/svc/PrintSvc',       // 有副作用，不延迟
    'reflect-metadata',        // 装饰器依赖，必须先加载
  ]
}

三层对比：

❌ 初级做法：不知道 inlineRequires 是什么
⚠️ 中级做法：知道改成 true 能优化，但无脑全开 → 副作用模块被延迟 → 崩溃
✅ 资深做法：开启 inlineRequires + 配置 blockList 排除副作用模块
   → 理解 import 的两种语义：声明依赖（可延迟）vs 执行副作用（不可延迟）

面试话术："inlineRequires 是 Metro 的编译时优化，把顶部 import 转换成使用时才执行的 require。这对 RN 启动性能很有帮助——我们项目 App.tsx 顶部有 20 个 import，全部在启动时执行。开启后只执行骨架代码，其他模块按需加载。但要注意有副作用的模块（如 reflect-metadata、全局初始化）需要通过 blockList 排除，否则会因延迟执行导致运行时错误。"

Q2：Hermes 不支持 JIT，为什么对 RN 反而更好？

用户回答：不理解 JIT 和 AOT 的区别，也不理解为什么放弃 JIT 是正确的。

暴露的知识盲区：对编译方式（AOT/JIT/解释执行）没有认知框架，不理解技术选型中"放弃什么换来什么"的权衡思维。

正确解答：

三种编译方式对比：

AOT（Ahead-Of-Time，提前编译）：
  开发时编译成字节码 → 运行时直接执行
  启动快，但运行时不做进一步优化
  → Hermes 用这种

JIT（Just-In-Time，即时编译）：
  运行时边执行边分析 → 发现"热点代码" → 编译成更快的机器码
  启动慢，但长时间运行越来越快
  → V8（Chrome/Node）和 JSC 用这种

解释执行：
  一行一行翻译，不编译
  最慢，但启动最快、最省内存

JIT 的优势在 RN 场景用不上：

JIT 擅长优化"执行很多次的热点代码"（比如一个 for 循环跑 10000 次）。但 RN 中 JS 的实际工作是：

JS 引擎在 RN 中的角色 = "指挥官"，不是"干活的人"

JS 做什么：
  "这个 View 宽 100，高 50，背景红色，里面放个 Text"
  → 描述 UI → 发给原生

谁干重活：
  原生引擎（UIKit + Yoga）→ 计算布局、渲染像素、执行动画
  → 这些是 C/C++ 代码，不经过 JS 引擎

所以 JS 函数的特点：
  ❌ 没有大量循环计算（JIT 的优势场景）
  ✅ 都是"调一次就完"的短函数（JIT 没机会优化）

JIT 的代价在移动端很致命：

Hermes 放弃 JIT 的算账：

丢掉的：长时间循环计算的极致性能
  → RN 几乎不做这种事，丢了也不心疼

得到的：启动快 50% + 内存降 40% + 省电
  → RN 急需的三个东西

结论 = 用"用不上的东西"换来"急需的东西" = 高 ROI 决策

类比：跑车发动机（JIT）vs 电动车（AOT）。在城市通勤（RN 场景）中，跑车的加速优势在红绿灯之间发挥不出来，反而油耗高、启动慢。电动车起步快、能耗低，完美匹配。

面试话术："Hermes 放弃 JIT 是一个典型的权衡决策。JIT 的优势在于长时间运行的热点代码优化，但 RN 的 JS 层只负责描述 UI 和调用原生方法，没有计算密集的循环——真正的渲染和动画是原生引擎做的。而 JIT 的代价——启动慢、内存高、耗电——恰好是移动端最敏感的指标。所以 Hermes 用 AOT 替代 JIT，放弃了用不上的运行时优化，换来了启动快 50% 和内存降 40%。这是典型的'知道不做什么'比'知道做什么'更重要的工程决策。"

14. Node.js 版本与 OpenSSL 兼容性：ERR_OSSL_EVP_UNSUPPORTED 排查

一句话结论

Node.js 17+ 内置的 OpenSSL 从 1.1 升级到 3.0，默认禁用了一些旧哈希算法（如 MD4），导致依赖这些算法的老版本构建工具（如 Metro 0.66）报 ERR_OSSL_EVP_UNSUPPORTED 错误，Xcode build 失败。

现象

Xcode build 时，原生代码编译全部通过，但到 "Bundle React Native code and images" 阶段（Metro 打包 JS Bundle）报错：

Failed to construct transformer: Error: error:0308010C:digital envelope routines::unsupported
  code: 'ERR_OSSL_EVP_UNSUPPORTED'

后续连锁错误：Cannot read properties of undefined (reading 'transformFile')（因为 Transformer 构造失败了，后续用 undefined 去调用方法）。

第一反应（可能的错误方向）

• 以为是 Metro 配置问题或缓存问题 → 其实不是
• 以为是 RN 代码有语法错误 → 其实原生编译阶段已经过了，JS 打包还没开始就崩了

排查思路

1. 看 build log 最后几行，而不是中间的 warning。真正的错误在 log 末尾
2. 关键词 ERR_OSSL_EVP_UNSUPPORTED + digital envelope routines → 这是 Node.js OpenSSL 3.0 的经典报错
3. 检查 Node 版本：node -v → v22.22.0（OpenSSL 3.x）
4. 检查 Metro 版本：0.66.2（老版本，内部用了 crypto.createHash 调用旧算法）

根因

OpenSSL 是什么？Node.js 为什么需要它？

OpenSSL 是一个开源的加密库，提供各种加密/哈希/签名算法的实现。你可以把它理解为"加密工具箱"。

Node.js 内置了 OpenSSL（编译进二进制文件），因为 Node 的 crypto 模块需要它来提供加密能力。当你在 Node 里写 require('crypto').createHash('md4') 时，底层调用链是：

你的 JS 代码
   │
   ▼
Node.js crypto 模块（JS 层，只是个包装器）
   │
   ▼
Node.js C++ binding（把 JS 调用转发给 C 库）
   │
   ▼
OpenSSL（真正执行 MD4 哈希运算的 C 库）

类比前端：就像浏览器内置了 V8 引擎来执行 JS，Node.js 内置了 OpenSSL 来执行加密运算。你用 crypto.createHash() 就像在浏览器里用 document.querySelector() — 你调的是 JS API，底层干活的是 C/C++ 实现。

什么是哈希？Metro 为什么需要它？

哈希是一种单向函数：输入任意长度的数据，输出固定长度的"指纹"。相同输入永远产生相同输出，不同输入（几乎）不会产生相同输出。

Metro 用哈希做构建缓存的 key。看实际代码：

// node_modules/metro-cache/src/stableHash.js:16-26
function stableHash(value) {
  return crypto
    .createHash("md4")                              // ← 就是这行！用 MD4 算法
    .update(JSON.stringify(value, canonicalize))     // 把配置对象序列化后计算哈希
    .digest("buffer");                               // 返回二进制哈希值
}

Metro 为什么需要这个？因为 Metro 有增量构建能力——第二次 build 时不需要重新转换所有 JS 文件，只处理改变了的。判断"有没有变"就靠哈希：

第一次 build：
  文件 A 的内容 + 转换配置 ──→ MD4 哈希 ──→ "a3f2b1..." ──→ 存入缓存

第二次 build：
  文件 A 的内容 + 转换配置 ──→ MD4 哈希 ──→ "a3f2b1..." ──→ 和缓存匹配！跳过转换 ✅
  文件 B 的内容（改了）    ──→ MD4 哈希 ──→ "7c9e4d..." ──→ 缓存没命中，重新转换 🔄

类比前端：这和 webpack 的 contenthash 完全一样。webpack 给打包输出的文件名加上 [contenthash].js，就是用哈希判断内容有没有变。Metro 在内部做了同样的事，只不过用的是 MD4 算法。

为什么 MD4 被禁用了？

Node.js 版本演进与 OpenSSL 的关系：

Node 16 及以下  ──→  内置 OpenSSL 1.1  ──→  支持 MD4/MD5 等旧算法  ✅
Node 17+        ──→  内置 OpenSSL 3.0  ──→  默认禁用旧算法         ❌

MD4 是 1990 年设计的哈希算法，早在 2004 年就被证明存在碰撞攻击（能人为构造两个不同的输入，产生相同的哈希值）。用于密码学目的（如证书签名）是危险的。

OpenSSL 3.0 把 MD4 归类为 legacy provider（遗留算法），默认不加载。虽然 Metro 用 MD4 只是做缓存 key（不涉及安全），但 OpenSSL 3.0 不区分用途——统一禁用了。

这不是 Metro 的 bug——Metro 0.66 发布时（2021 年底），Node 17 还刚发布，大多数人用 Node 14/16。后来 Node 升级了底层 OpenSSL，导致不兼容。

有趣的事实：webpack 4 也用了 MD4 做 contenthash，所以 webpack 4 + Node 17+ 同样会报这个错。webpack 5 改成了 xxhash64（更快且没有 OpenSSL 依赖）。Metro 的新版本也做了类似的迁移。

本质理解：为什么 Node.js 要升级 OpenSSL

OpenSSL 1.1 在 2023 年 9 月停止维护（EOL），不再修复安全漏洞。Node.js 必须跟进升级到 OpenSSL 3.0，但 3.0 的安全策略更严格——禁用了被认为不安全或过时的算法。这是安全性 vs 向后兼容的取舍，Node.js 选择了安全性。

这种取舍在软件工程中很常见：底层依赖的安全升级，逼迫上层生态跟着适配。类似于 iOS 每年大版本升级后，一堆第三方 SDK 需要适配——不是它们有 bug，而是平台规则变了。

修复方案对比

❌ 初级做法：盲目降级 Node 到 v12/v14
   → 问题：这些版本也 EOL 了，有安全风险，且其他工具可能需要更高版本

⚠️ 中级做法：设置 NODE_OPTIONS=--openssl-legacy-provider
   → 原理：告诉 Node "允许使用旧算法"，相当于打开一个兼容开关
   → 隐患：治标不治本，且 --openssl-legacy-provider 在未来 Node 版本可能被移除
   → 适用场景：不想改全局 Node 版本，只想快速解决 Xcode build

✅ 资深做法：用 nvm 管理 Node 版本，项目级别指定兼容版本
   → 原理：nvm alias default 16 或项目 .nvmrc 文件指定版本
   → 优势：不同项目用不同 Node 版本，互不影响
   → 根本解决：升级 RN 和 Metro 到新版本（支持 OpenSSL 3.0）

--openssl-legacy-provider 到底做了什么？

OpenSSL 3.0 引入了 Provider 架构——把算法按安全等级分组：

OpenSSL 3.0 的 Provider 架构：

┌─────────────────────────────────────────────────┐
│                  OpenSSL 3.0                     │
│                                                  │
│  ┌──────────────┐  ┌──────────────┐  ┌────────┐ │
│  │ default      │  │ legacy       │  │ fips   │ │
│  │ provider     │  │ provider     │  │provider│ │
│  │              │  │              │  │        │ │
│  │ SHA-256 ✅   │  │ MD4    ⚠️    │  │ 合规   │ │
│  │ SHA-512 ✅   │  │ MD5    ⚠️    │  │ 算法   │ │
│  │ AES    ✅   │  │ RC4    ⚠️    │  │ 专用   │ │
│  │ ...现代算法  │  │ ...过时算法   │  │        │ │
│  └──────────────┘  └──────────────┘  └────────┘ │
│       默认加载 ✅       默认不加载 ❌              │
└─────────────────────────────────────────────────┘

当你设置 NODE_OPTIONS=--openssl-legacy-provider，就是告诉 Node.js："启动时除了加载 default provider，也把 legacy provider 加载进来"。这样 crypto.createHash('md4') 就能在 legacy provider 里找到 MD4 的实现。

类比前端：类似于浏览器的 polyfill。--openssl-legacy-provider 就像给 OpenSSL 3.0 加了一个 polyfill，让它能执行旧版本支持但新版本移除的算法。

为什么说它"治标不治本"？因为：

1. 这个 flag 是 Node.js 提供的临时兼容方案，未来 Node 版本可能移除
2. 它让整个进程都能用不安全的算法，而不只是 Metro 这一处
3. 真正的问题是 Metro 不应该用 MD4 — 应该升级 Metro

nvm 的工作原理：它怎么实现多版本切换？

nvm（Node Version Manager）的核心原理非常简单：操作 PATH 环境变量。

nvm 的安装结构：

~/.nvm/
├── versions/
│   └── node/
│       ├── v14.21.3/       ← 每个版本一个完整的 Node 安装目录
│       │   └── bin/
│       │       ├── node    ← 这个版本的 node 二进制文件
│       │       └── npm
│       ├── v16.20.2/
│       │   └── bin/
│       │       ├── node
│       │       └── npm
│       └── v22.22.0/
│           └── bin/
│               ├── node
│               └── npm
├── alias/
│   └── default → v16.20.2  ← nvm alias default 16 就是改这个指向
└── nvm.sh                   ← nvm 本身是个 shell 函数（不是可执行文件）

当你执行 nvm use 16 时，nvm 做的事只有一件：

# 简化版的 nvm use 原理
export PATH="$HOME/.nvm/versions/node/v16.20.2/bin:$PATH"
# 把 v16 的 bin 目录插到 PATH 最前面
# 这样 shell 搜索 `node` 命令时，第一个找到的就是 v16 的 node

类比前端：nvm 的原理就像 npm 的 .bin 目录。当你 npx webpack 时，npm 会把 node_modules/.bin 加到 PATH 前面，让 shell 找到项目本地的 webpack 而不是全局的。nvm 用同样的原理，只是管理的是 Node 本身。

为什么 nvm use 只影响当前终端？ 因为 export PATH=... 只修改当前 shell 进程的环境变量。每个终端是独立的 shell 进程，互不影响。

nvm alias default 做了什么？ 它修改了 ~/.nvm/alias/default 文件的指向。当 nvm.sh 被新终端 source 时，它读取 default alias 并自动执行 nvm use <default版本>。所以 nvm alias default 16 = "以后每个新终端默认用 Node 16"。

我们采用的方案

nvm alias default 16    # 将默认 Node 版本设为 16.20.2

关键发现：Xcode Build Phase 如何找到 Node

Xcode 的 Build Phase 脚本用 /bin/sh 执行，不会读取你的 .zshrc。但 RN 0.66 的 find-node.sh（node_modules/react-native/scripts/find-node.sh）会主动 source ~/.nvm/nvm.sh：

# find-node.sh 关键代码（第 16-24 行）
[ -z "$NVM_DIR" ] && export NVM_DIR="$HOME/.nvm"

if [[ -s "$HOME/.nvm/nvm.sh" ]]; then
  . "$HOME/.nvm/nvm.sh"              # ← 主动加载 nvm
elif [[ -x "$(command -v brew)" && -s "$(brew --prefix nvm)/nvm.sh" ]]; then
  . "$(brew --prefix nvm)/nvm.sh"
fi

完整的 node 发现优先级链（find-node.sh 按顺序尝试）：

find-node.sh 的搜索顺序：

1. Homebrew M1 路径 (/opt/homebrew/bin)  ──→ 加到 PATH
2. nvm (~/.nvm/nvm.sh)                   ──→ source 加载，根据 default alias 找 node
3. nodenv (~/.nodenv/bin/nodenv)          ──→ eval init，根据 .node-version 找 node
4. anyenv (~/.anyenv/bin)                 ──→ eval init，通过 ndenv 找 node
5. 以上都没有 → 用 PATH 中已有的 node

我们的情况是走到第 2 步：nvm 被加载，读取 default alias（已改为 16），所以 Xcode build 时用 Node 16.20.2。

与前端已知知识的类比

这和前端 webpack 的情况一模一样：

Xcode Build 完整流程：从按下按钮到 App 启动

Cmd+B (Build) vs Cmd+R (Run) 的区别

Xcode Build 的详细阶段（对应我们项目）

当你按下 Cmd+B 或 Cmd+R 时，Xcode 按顺序执行以下 Build Phases：

按下 Cmd+R
   │
   ▼
┌─ Phase 1: [CP] Check Pods Manifest.lock ─────────────────────┐
│  检查 Pods 依赖有没有变化，确保和 Podfile.lock 一致            │
│  类比：npm ci 时检查 package-lock.json 有没有过期              │
└──────────────────────────────────────────────────────────────┘
   │
   ▼
┌─ Phase 2: Compile Sources ───────────────────────────────────┐
│  编译所有 .m / .swift 原生源代码为 .o 目标文件                 │
│  → build log 里大量的 CompileC 和 CompileSwift 就是这一步      │
│  → 中间那些 nullability warning 就是这一步产生的               │
│  类比：TypeScript 的 tsc 编译阶段                             │
└──────────────────────────────────────────────────────────────┘
   │
   ▼
┌─ Phase 3: Link Frameworks ──────────────────────────────────┐
│  把 .o 文件 + 第三方 framework 链接成一个可执行文件             │
│  类比：webpack 把各个 chunk 打包成最终的 bundle                │
└──────────────────────────────────────────────────────────────┘
   │
   ▼
┌─ Phase 4: Copy Resources ───────────────────────────────────┐
│  把图片、字体、音频等资源文件复制到 .app 包中                   │
│  类比：webpack 的 CopyPlugin 把 public/ 目录复制到 dist/      │
└──────────────────────────────────────────────────────────────┘
   │
   ▼
┌─ Phase 5: Embed Frameworks ─────────────────────────────────┐
│  把动态链接的 framework 嵌入 .app 包中                        │
│  （静态库在 Phase 3 已经编进去了，动态库需要单独嵌入）          │
└──────────────────────────────────────────────────────────────┘
   │
   ▼
┌─ Phase 6: Bundle React Native code and images ★ ────────────┐
│  ★ 这次报错就发生在这里！                                     │
│  执行 react-native-xcode.sh 脚本：                           │
│    1. find-node.sh 找到 node 可执行文件                       │
│    2. 运行 Metro bundler 把所有 JS/TS 打包成 main.jsbundle    │
│    3. 把 jsbundle + JS 引用的图片 复制到 .app 包中             │
│  类比：前端项目的 npm run build 阶段                          │
└──────────────────────────────────────────────────────────────┘
   │
   ▼
┌─ Phase 7: Sentry (上传 sourcemap) ──────────────────────────┐
│  把 debug 符号上传到 Sentry，用于线上 crash 的堆栈还原         │
│  类比：前端把 sourcemap 上传到 Sentry                         │
└──────────────────────────────────────────────────────────────┘
   │
   ▼
┌─ Phase 8: Code Signing ─────────────────────────────────────┐
│  用开发者证书对 .app 签名（iOS 强制要求）                      │
│  没有有效签名的 app 无法安装到设备上                           │
│  类比：前端没有对应概念，但类似于 npm publish 需要 auth token  │
└──────────────────────────────────────────────────────────────┘
   │
   ▼ （以下只有 Cmd+R 才会执行）
┌─ Phase 9: Install & Launch ─────────────────────────────────┐
│  把签名好的 .app 通过 USB/WiFi 安装到设备，然后启动            │
│  类比：npm run build && npx serve dist（打包后启动服务）       │
└──────────────────────────────────────────────────────────────┘

关键洞察：Build 在 Phase 6 挂了，说明 Phase 1-5（原生代码编译）全部成功了。问题完全出在 JS 打包环节。这就是为什么 build log 中间的 warning（nullability 之类的）都是假信号——原生部分根本没有出错。

经验提炼

1. Build log 看末尾：Xcode build 失败时，真正的错误通常在 log 最后几行，中间大量 warning 可以先忽略
2. ERR_OSSL_EVP_UNSUPPORTED = Node 版本过高：这是一个高频问题，遇到就检查 Node 版本
3. nvm 是 Node 版本管理的标配：不同项目可能需要不同 Node 版本，用 nvm alias default 设全局默认，用 .nvmrc 设项目级别

举一反三

同类问题：底层依赖升级导致上层工具链 break

ERR_OSSL_EVP_UNSUPPORTED 不只出现在 RN 项目。这是一个通用模式——底层平台/运行时升级了安全策略，上层工具来不及适配：

通用认知模型：

时间线：
  2021        2022        2023        2024        2025
    │           │           │           │           │
    │ Metro 0.66│           │           │           │
    │ 发布     │           │ OpenSSL 1.1│           │
    │ (用 MD4) │           │ EOL       │           │
    │           │ Node 17   │           │ Node 22   │
    │           │ 换 OpenSSL│           │ 已经没有  │
    │           │ 3.0       │           │ legacy    │
    │           │           │           │ 退路了    │
    ▼           ▼           ▼           ▼           ▼

  规律：工具发布时基于当时的运行环境，运行环境升级后工具就可能 break。
  版本越老，和当前环境的"距离"越远，break 的概率越高。

通用解决思路：降运行时版本（快速止血） 或 升级工具到适配新运行时的版本（根本解决）。

系统思维：为什么不能永远停在 Node 16？

Node 16 已于 2023 年 9 月 EOL。停在 Node 16 意味着：

• 不再有安全补丁 → 有 CVE 漏洞时无法修复
• npm 生态新包逐渐 drop 对 Node 16 的支持
• CI/CD 平台（如 GitHub Actions）逐渐移除 Node 16 runner

正确的演进路径：Node 16 是止血方案，真正要做的是升级 RN 版本（新版 Metro 已经把 MD4 换成了 SHA-256 或其他现代算法）。但升级 RN 是大工程，需要评估 ROI。

面试 / 技术对话角度

面试官可能怎么问：

• 初级：你遇到过什么构建问题？怎么解决的？
• 资深：Node.js 大版本升级时有哪些 breaking change 需要注意？你们团队怎么管理 Node 版本？

面试话术："我在 RN 项目中遇到过一个典型的 Node 版本兼容问题——Node 17 以后升级了内置的 OpenSSL 到 3.0，默认禁用了旧加密算法，导致老版本的 Metro bundler 在 Xcode build 时报 ERR_OSSL_EVP_UNSUPPORTED。排查时关键是读 build log 末尾而不是被中间的 warning 干扰。解决方案是用 nvm 管理 Node 版本，项目级别指定兼容版本。这个经验让我意识到，构建工具链的版本管理和业务代码一样重要——我们后来在项目里加了 .nvmrc 文件，确保团队成员用一致的 Node 版本。"

延伸讨论：

• "为什么不直接用 --openssl-legacy-provider？" → 治标不治本，这个 flag 未来可能被移除，而且掩盖了真正的版本不兼容问题
• "根本解决方案是什么？" → 升级 RN 和 Metro 到支持 OpenSSL 3.0 的版本，但这涉及大量适配工作，需要评估 ROI
• "你们团队怎么统一 Node 版本？" → .nvmrc 文件 + CI 中固定 Node 版本 + 团队规范

思考题讨论

Q1：webpack 5 为什么选 xxhash64 而不是 SHA-256 做 contenthash？

知识盲区：不了解加密哈希和非加密哈希的区别，以及构建工具对哈希的需求是什么。

完整解答：

哈希算法分两大类，设计目标完全不同：

webpack/Metro 用哈希只是为了生成构建缓存的 key——判断"这个文件改没改"。这个场景：

• 不需要防攻击：没有人会故意构造两个不同的 JS 文件来欺骗 webpack 缓存
• 非常需要快：大项目有几千个文件，每个都要算哈希，速度直接影响构建时间
• 不应依赖 OpenSSL：依赖系统级加密库会被运行时版本 break（这次我们就踩了这个坑）

webpack 5 的决策思路：

需求：给文件内容生成指纹
  │
  ├── 需要防攻击？ → 不需要
  ├── 需要快？     → 非常需要
  ├── 需要跨平台稳定？ → 需要（不能依赖 OpenSSL）
  │
  └── 结论：xxhash64
       → 速度比 SHA-256 快 10-20 倍
       → 纯 JS/WASM 实现，不依赖 OpenSSL
       → 碰撞率足够低，完全满足缓存场景

一句话总结：用 SHA-256 做缓存 key 就像用保险柜锁来锁厕所门——安全是安全了，但没必要，还慢。

三层对比：

❌ 初级认知：哈希就是哈希，SHA-256 最安全所以最好
   → 问题：过度设计，在不需要安全性的场景浪费性能

⚠️ 中级认知：知道 MD5 不安全，应该用 SHA-256
   → 问题：只有"安全/不安全"一个维度，没考虑"是否需要安全"

✅ 资深认知：先判断场景需求（需要抗攻击？需要快？需要跨平台？），再选算法
   → 构建缓存 key → xxhash64（快，不依赖系统库）
   → 用户密码存储 → bcrypt/argon2（慢是特性，防暴力破解）
   → 文件完整性校验 → SHA-256（需要防篡改）

面试话术："哈希算法的选择要看场景。比如 webpack 5 把 contenthash 的算法从 MD4 换成了 xxhash64，而不是换成更安全的 SHA-256——因为构建缓存 key 不需要抗碰撞攻击，只需要快和稳定。xxhash64 比 SHA-256 快 10-20 倍，而且是纯 JS 实现不依赖 OpenSSL，避免了被 Node.js 版本升级 break 的风险。这体现了一个资深工程师的判断：选技术方案不是选'最好的'，而是选'最匹配需求的'。"

Q2：nvm use 16 → nvm use 22，PATH 里会有两个版本吗？

知识盲区：不确定 nvm 切换版本是"堆叠"还是"替换"PATH。

完整解答：

不会有两个版本同时在 PATH 里。nvm 是"先删后加"——替换，不是堆叠。

初始 PATH：
/usr/local/bin:/usr/bin:/bin

执行 nvm use 16 后：
/Users/mac/.nvm/versions/node/v16.20.2/bin:/usr/local/bin:/usr/bin:/bin
↑ 插入 v16 路径

执行 nvm use 22 后：
/Users/mac/.nvm/versions/node/v22.22.0/bin:/usr/local/bin:/usr/bin:/bin
↑ v16 被移除，替换成 v22（不是在 v16 前面再加一层）

nvm 在 nvm.sh 内部用字符串操作，把 PATH 中之前的 nvm node 路径删掉，再插入新版本路径。

如果不移除旧的会怎样？ PATH 会变成 v22/bin:v16/bin:...。shell 搜索 node 时找到 v22（在前面），v16 永远不会被用到。虽然"能用"，但：

• 每次 nvm use 都堆一层，PATH 越来越长
• 这是一种内存泄漏式的设计——不释放不再需要的东西
• PATH 过长会导致 shell 命令查找变慢

所以 nvm 选择干净的替换策略。

类比前端：这就像 React 的 useState。setCount(5) 不是在旧的 count 旁边再加一个 5——它用新值替换旧值。nvm 对 PATH 的操作是同样的"替换"语义，不是"追加"。