Flutter入门实战：从手写党到跨端新兵的血泪踩坑记
上周五晚上十点半，我正窝在沙发上啃着冷掉的披萨，一边盯着 Kubernetes 集群里某个 Pod 死活起不来，一边刷朋友圈——结果看到前同事晒出他用 Flutter 写的跨平台 App，iOS 和 Android 界面一模一样，性能还不赖。我第一反应是：“这玩意儿不是玩具吗？”
但转念一想，我们组最近要搞个内部工具，老板拍板说“必须同时支持手机和平板”，而前端人手紧张，后端老王又嚷嚷着“别让我再碰 React Native 了，上次打包崩溃差点把我送走”……得，看来我也得下水试试 Flutter 了。
作为一个常年手写 Go 和 Rust、连 IDE 自动补全都嫌吵的老派程序员，我对 AI 辅助写代码的态度向来是“能不用就不用”。但这次，面对一个全新的 UI 框架，我不得不承认：光靠看源码和文档，效率太低了。于是，我一边开着 VS Code 手敲每一行 Dart 代码，一边偷偷让 GitHub Copilot 帮我生成几个 Widget 结构——保守归保守，deadline 面前，谁还顾得上清高？
为什么选 Flutter？真不是跟风
其实我们团队去年双11期间就讨论过跨端方案。React Native？历史包袱重，热更新受限，而且 iOS 审核越来越严。uni-app？性能一般，定制性差。最后大家一致觉得：要么原生双端开发（人力翻倍），要么赌一把 Flutter。
我私下研究了几个主流开源项目（比如 Flutter Gallery 和 InKino），发现 Dart 虽然小众，但语法干净，AOT 编译后性能接近原生，而且 Widget 树的设计哲学很对我的胃口——一切皆组件，状态驱动 UI，和 React 的思路异曲同工，但更“纯”。
更重要的是：一套代码，两套平台，还能跑 Web 和桌面（虽然生产环境慎用）。对我们这种远程办公、人少事多的小团队来说，简直是救命稻草。
工具链搭建：别被“简单”骗了
官方文档说“5 分钟上手”，我信了，结果光是环境配置就折腾了俩小时。
首先，Dart SDK 和 Flutter SDK 得装。我习惯用 asdf 管理多版本语言，但 Flutter 官方推荐直接下载 ZIP 包解压。行吧，听你的。配置完 PATH，运行 flutter doctor，结果报了一堆红：
[✗] Android toolchain - develop for Android devices
✗ Unable to locate Android SDK.
[✗] Xcode - develop for iOS devices
✗ Xcode not installed.
我：？？？我家是 Linux 服务器 + macOS 笔记本双机党，Android SDK 在服务器上，Xcode 在笔记本上，这怎么搞？
最后妥协方案：主力开发用 Mac，Android 模拟器跑在本地，iOS 直接真机调试。至于 CI/CD，等后面再说吧——毕竟 MVP 阶段，先跑起来再说。
小贴士：如果你也用 Linux 开发 Flutter，建议只做 Android 开发；想搞 iOS，Mac 是刚需。别跟我一样幻想“Linux 编译 iOS”，那是在做梦。
第一个 App：Hello World 背后的坑
按照教程，flutter create my_app，然后 flutter run，一个计数器 App 就跑起来了。看起来很美好，对吧？
但当我尝试改成自己的业务逻辑时，问题来了：
- 状态管理怎么选？ Provider？Bloc？Riverpod？Redux？官方示例用的是
setState，但那只是玩具。我翻了 GitHub 上 star 最高的几个项目，发现 Provider + Riverpod 组合目前最流行，尤其适合中小型项目。 - 网络请求用啥？
http包太裸，最后选了dio，支持拦截器、超时、Cookie，和 Axios 差不多。 - UI 适配太头疼！ iPhone 14 Pro Max 和小米 13 的屏幕比例、安全区域完全不一样。光靠
MediaQuery不够，还得用LayoutBuilder+FractionallySizedBox做响应式布局。
最崩溃的是上周三下午，我写了个登录页，按钮在 iOS 上显示正常，在 Android 上却被键盘顶飞了。查了半天，才发现要用 SingleChildScrollView 包裹整个表单，并设置 resizeToAvoidBottomInset: true。当时真的想砸电脑。
实战经验：那些没人告诉你的细节
1. 平台差异不能忽视
虽然 Flutter 宣称“一次编写，到处运行”，但现实很骨感。比如：
- 字体渲染：iOS 默认用 San Francisco，Android 用 Roboto，你如果不显式指定，UI 会微妙地不一致。
- 导航栏高度：Android 有返回键，iOS 没有；刘海屏、挖孔屏的安全区域也要单独处理。
- 权限请求：Android 要动态申请权限，iOS 要在
Info.plist里声明。我第一次提交 TestFlight，就因为没加相机权限被拒了。
解决方案？善用 Platform.isIOS / Platform.isAndroid 做条件判断，或者用 flutter_platform_widgets 这类包自动适配。
2. 性能优化：别让动画卡成 PPT
我们内部工具有个数据看板，表格滚动时掉帧严重。Profiler 一看，好家伙，每个 Cell 都在 rebuild！
后来改用 ListView.builder + const 构造函数 + Key 优化，帧率立马稳在 60fps。记住：能用 const 就用 const，能用 Key 就用 Key，避免不必要的 rebuild。
3. 发布上架：比写代码还累
Android 打包还算顺利，但 iOS 提交 App Store 简直是炼狱：
- 必须用 Xcode Archive
- Bundle ID 不能重复
- 截图要覆盖所有设备尺寸
- 隐私描述必须写清楚（哪怕你根本没用定位）
我花了整整一天才搞定 TestFlight 内测。测试妹子反馈：“App 启动有点慢”，一查发现是首屏加载了太多资源。后来用了 懒加载 + 骨架屏，体验好多了。
工具与教程推荐（亲测有效）
| 类型 | 推荐 | 说明 |
|---|---|---|
| 官方教程 | Flutter 官网 Codelabs | 从基础到进阶，动手性强 |
| 社区教程 | 《Flutter 实战》电子书（掘金） | 国内作者，贴近实际场景 |
| UI 库 | Flutter Awesome | 插件 & 组件大全 |
| 调试工具 | DevTools | 内存、性能、Widget 树分析神器 |
| 状态管理 | Riverpod | 比 Provider 更灵活，支持异步 |
特别提醒：别一上来就学复杂的状态管理！先用 setState 把功能跑通，再重构。我见过太多人卡在 Bloc 的 Event/State 设计上，三天没写出一行业务逻辑。
写在最后：手写党的新感悟
说实话，用 Flutter 一周后，我对“手写代码”的执念松动了。不是说我不坚持了，而是意识到：工具的价值在于解放生产力，而不是彰显情怀。Copilot 帮我生成了 30% 的样板代码，我省下时间去优化架构和用户体验，何乐不为？
当然，核心逻辑我还是亲手敲的——比如那个自定义的 K8s 资源展示组件，每一行都经过深思熟虑。毕竟，AI 能帮你写代码，但写不出对业务的理解。
现在，我们的内部工具已经上线两周，Android 和 iOS 用户反馈都不错。产品经理甚至说：“下次新功能全用 Flutter 做吧！”——虽然我知道他下周可能又要改需求，但至少这次，我不用同时维护两套代码了。
如果你也是个手写党，正在观望 Flutter，我的建议是：别犹豫，先跑个 Demo。踩坑不可怕，可怕的是用十年前的思维做今天的事。
毕竟，在这个卷成麻花的行业里，能省一个人力，就能多活一个月。
评论 0