环境与工具链准备：搭建开发环境、版本管理、包管理器与调试配置
说实话，界面移植这个活儿，百分之六十的坑其实在动手之前就已经埋下了。我见过太多团队，代码写得挺漂亮，结果环境不一致，一跑就崩。嗯，今天咱们就把地基打牢。
2.1 开发环境搭建：别让“在我电脑上能跑”成为笑话
移植工作最怕什么？最怕源环境和目标环境差太多。我个人习惯是，每接手一个移植项目，第一件事就是拉一份环境清单。
| 环境项 | 源端（旧平台） | 目标端（新平台） | 注意事项 |
|---|---|---|---|
| 操作系统版本 | macOS 12.6 | Windows 11 22H2 | 路径分隔符、换行符差异 |
| 语言运行时 | Node 18.16 | Node 20.10 | API 废弃与新增 |
| 构建工具 | Webpack 5 | Vite 5 | 模块解析规则不同 |
| 目标设备 SDK | Android API 30 | Android API 34 | 权限模型、渲染管线变化 |
我曾经遇到过一件事：团队从 React Native 0.63 往 0.73 移植，结果因为没统一 Node 版本，Hermes 引擎编译出来的字节码不兼容，白屏了两天。说白了，环境版本号差一个 minor，可能就是天壤之别。
.packages 文件里路径分隔符写死了。所以，环境配置必须脚本化，别手配。
2.2 版本管理（Git）：你的后悔药和时光机
移植过程中，你一定会改很多代码。改着改着发现方向错了，想回退？Git 就是你的救命稻草。但怎么用，有讲究。
2.2.1 分支策略：别在主分支上动刀
我个人建议，移植工作单独开一个分支。比如从 main 拉一个 feat/port-to-v2。这样源版本的 bug 修复还能合进来，互不干扰。
# 从主分支拉取移植专用分支
git checkout -b feat/port-to-v2 main
# 定期同步主分支的修复
git fetch origin
git rebase origin/main
git rebase 而不是 git merge，能让你的提交历史是一条直线，回头排查问题的时候，心里不堵。
2.2.2 提交粒度：原子化提交
你想想看，如果一次提交改了 50 个文件，里面既有样式调整，又有逻辑重构，还有 API 替换。三天后发现样式改错了，你怎么回滚？
我习惯的规则是：一个提交只做一件事。比如：
feat: 替换网络请求库从 axios 到 fetchfix: 修复 Android 端状态栏高度适配refactor: 抽取主题变量为独立文件
这样做的好处是，你可以用 git bisect 快速定位引入 bug 的提交。我曾经靠这个功能，在 200 多个提交里，十分钟就找到了罪魁祸首。
2.2.3 忽略文件：别把垃圾带进仓库
移植项目经常会有平台特有的生成文件。比如 iOS 的 .xcworkspace、Android 的 .gradle、Windows 的 .vs 文件夹。这些必须写进 .gitignore。
# .gitignore 示例片段
# 平台构建产物
build/
dist/
*.apk
*.ipa
# IDE 配置
.idea/
.vscode/
*.swp
# 依赖目录
node_modules/
.packages/
node_modules 提交到 Git 仓库，结果仓库体积直接飙到 2GB，clone 一次半小时。记住，依赖不提交，环境靠锁文件。
2.3 包管理器：npm、pip、pub 的选择与锁文件
包管理器是移植工作的“物流系统”。选对了，事半功倍；选错了，依赖地狱等着你。
| 平台/语言 | 推荐包管理器 | 锁文件 | 我的经验 |
|---|---|---|---|
| Web/Node.js | pnpm / npm | pnpm-lock.yaml |
pnpm 节省磁盘，硬链接机制在移植多项目时很香 |
| Python | pip + venv | requirements.txt |
一定要用虚拟环境，全局安装会打架 |
| Flutter/Dart | pub | pubspec.lock |
锁文件必须提交，否则队友会哭 |
| iOS (CocoaPods) | bundler + pod | Podfile.lock |
版本锁定极其严格，差一个 build 都可能编译不过 |
为什么锁文件这么重要？说白了，它锁定了每个依赖的精确版本。没有锁文件，你同事 npm install 出来的 left-pad 可能是 1.0.0，你的是 1.3.0，行为不一样，bug 就来了。
2.4 模拟器与真机调试配置
代码写完了，总得跑起来看看。模拟器快，真机准，两者缺一不可。
2.4.1 模拟器配置：快跑迭代
我个人习惯，在移植初期，90% 的时间用模拟器。因为启动快、截图方便、日志清晰。
- Android Emulator： 用 x86_64 镜像，开启 GPU 加速。别用 ARM 镜像，慢得你想砸电脑。
- iOS Simulator： 选真机对应的设备类型。注意，模拟器不提供传感器数据（比如陀螺仪），需要 mock。
- Windows 模拟器： 用 Windows App SDK 的模拟器，或者直接跑本地桌面窗口。
# 启动 Android 模拟器并指定端口
emulator -avd Pixel_6_API_34 -port 5554 -no-snapshot
# iOS 模拟器命令行启动
xcrun simctl boot "iPhone 15 Pro"
2.4.2 真机调试：验证最终效果
模拟器跑得再好，也替代不了真机。为什么？因为模拟器用的是你电脑的显卡和 CPU，真机的硬件性能、屏幕像素密度、触控采样率都不一样。
我曾经移植一个地图应用，在模拟器上滑动流畅得像德芙，上了真机就卡成 PPT。最后发现是模拟器默认开启了 2x 渲染，真机是 3x，纹理内存爆了。
- 开启开发者模式（Android 点 7 次版本号，iOS 连 Xcode 注册设备）
- 开启 USB 调试 / 网络调试
- 检查日志输出：
adb logcat或 Xcode Console - 测试弱网环境：用 Charles 或 Proxyman 模拟 3G 网络
2.4.3 远程调试：跨设备协作
如果你在 Windows 上开发，但目标设备是 iPhone，怎么办？可以用远程调试。
- React Native / Flutter： 支持 WiFi 热重载。手机和电脑连同一个局域网，用 IP 连接。
- Web 页面： 用
ngrok或localtunnel把本地服务暴露到公网，手机扫码访问。 - Chrome DevTools： 用
chrome://inspect调试 Android WebView。
# 使用 adb 进行 WiFi 调试
adb tcpip 5555
adb connect 192.168.1.100:5555
2.5 本章知识体系总览
下面这张图，把咱们刚才聊的内容串起来了。你可以把它当作移植前的检查清单。
嗯，环境与工具链这部分，说白了就是“磨刀不误砍柴工”。你把这些配置都跑通了，后面写代码的时候，心里才有底。别急着写代码，先把刀磨快。