我最早注意到 Flutter-Notebook 这个项目，是把它当作一个巨大的示例代码库来用的。它几乎覆盖了 Flutter 开发中能遇到的所有常见场景：网络请求、状态管理、动画、数据库、自定义绘制、原生插件调用……对于想快速验证某个想法的人来说，直接翻到对应 demo 抄一段，比重新搭工程快得多。但用得越深，我越意识到一个问题：正因为 Flutter-Notebook 里集成了大量的第三方库和原生交互代码，一旦你基于它去搭建生产环境应用，或者直接把它打包上线，代码混淆和平台安全配置就完全绕不开了——这恰恰是这个项目最容易被忽视的深水区。
很多人以为 Flutter 编译后的产物天然安全，Dart 代码会被编译成机器码或者 AOT 快照，没法直接看懂。这个想法对了一半。实际上 Flutter 应用的暴露面比想象中大得多：Dart 层虽然经过编译，但字符串、类名、方法名在不少场景下仍然可以还原；Android 原生层的 Java/Kotlin 代码如果不做混淆，用 jadx 一打开，整个业务逻辑基本等于裸奔；iOS 侧虽然没有 Java 层那么直观，但 class-dump 一样能提取出可读性极高的 ObjC 头文件信息。
所以 Flutter-Notebook 代码混淆这套东西，说到底是三层防线：Dart 层、Android 原生层、iOS 原生层。每一层的配置思路不同，工具链不同，踩坑方式也不同。下面把我实际操作中的完整方案和排错过程整理出来，按平台拆开讲。
1. 先搞明白 Flutter-Notebook 的安全边界：三层代码分别暴露了什么
1.1 一个常被忽略的事实：Dart 层和原生层要分开看
Flutter 应用从代码角度看，通常由两部分组成：用 Dart 写的业务逻辑，以及用 Java/Kotlin（Android）和 ObjC/Swift（iOS）写的平台特定代码。这两部分的安全性是完全独立的。
Dart 层在 release 模式下默认走 AOT 编译，生成的是快照文件。很多人以为这个快照没法反编译，实际上 Flutter 官方自己也承认，Dart AOT 快照在缺乏混淆的情况下，可以通过符号信息还原出大部分类名和方法名。尤其是 Flutter 1.17 之前的老项目，连 --obfuscate 参数都没有，基本上属于"脱了壳的鸡蛋"。Flutter-Notebook 里大量 demo 代码本身可读性就很高，一旦上线，某些代码的用途几乎一眼就能看穿。
原生层更直接。Android 的 APK 用 jadx 打开，Java/Kotlin 代码如果没有 ProGuard/R8 做混淆，包名、类名、方法名一目了然。Flutter-Notebook 里那些原生插件封装、渠道跳转逻辑、SharedPreferences 存储结构，全都会暴露给逆向者。iOS 侧虽然不能在非越狱设备上直接 dump 内存，但砸壳之后拿 class-dump 提取头文件，照样能把主要类结构翻个底朝天。
1.2 Flutter-Notebook 为什么更需要一套完整混淆配置
我曾经见过有人直接把 Flutter-Notebook 的某个 demo 作为核心业务模块集成到商业 App 里。这种做法本身没问题，问题在于 Flutter-Notebook 的代码风格是"为演示服务"的——它保证可读性，不考虑隐藏逻辑，也不设置任何防护。它的代码里通常包含大量的业务关键词、接口路径、密钥测试值、第三方 App 跳转 scheme，这些恰恰是逆向者最想要的入口信息。
如果稍微做一下混淆，这些人就得多花几倍的时间去还原逻辑。如果完全不配置，那相当于把 Flutter-Notebook 的示例代码原封不动交到别人手上，顺带还附赠了一套完整的 Flutter 学习资料。这不只是"不设防"的问题，而是主动提供攻击面。
另外，这类项目往往集成了很多第三方 SDK。第三方 SDK 的混淆规则如果处理不好，release 包轻则运行崩溃，重则数据上报全丢、广告拉不起来、支付回调失效。这套坑我在 Flutter-Notebook 上几乎全都踩过。
1.3 混淆能够挡住什么，挡不住什么
这里必须泼一盆冷水：代码混淆是"增加逆向成本"，不是"让逆向完全不可能"。它能挡住的是大多数脚本小子、爬虫工程师和初级逆向者。一个真正有耐心的逆向工程师，配合动态调试、内存 dump、Frida Hook 这些手段，最终还是能还原你绝大部分逻辑。
所以我的原则很明确：混淆的目的是把攻击成本抬高到超过收益。对 Flutter-Notebook 这类项目来说，把默认的 demo 代码变成不可直接阅读的产物，同时保证核心业务在可接受的性能损耗下正常运行，就已经达到目的了。不要追求绝对安全，那属于商业级加固方案的范畴，不是一篇博客能解决的。
2. Android 侧配置：R8、ProGuard 与 Dart 混淆三层叠加
2.1 第一步：开启 release 构建的代码压缩与资源瘦身
Android 侧的混淆体系核心是 R8 编译器。在较新的 Gradle 插件版本中，R8 已经取代了 ProGuard，默认开启代码压缩、资源收缩和混淆。但 Flutter-Notebook 项目里的 build.gradle 文件通常保留了最朴素的默认配置，需要手动设置。
打开android/app/build.gradle，在buildTypes中找到release，确认里面的配置：
android { buildTypes { release { // 启用代码压缩、资源收缩和混淆 isMinifyEnabled = true isShrinkResources = true proguardFiles( getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro" ) } } }注意 Kotlin DSL 和 Groovy DSL 的写法略有区别，上面是 Groovy 风格。如果项目用的是 Kotlin DSL，属性名要写成isMinifyEnabled = true，因为minifyEnabled在 Kotlin DSL 里可能存在二义性。
isShrinkResources的本意是配合代码混淆，删除未被引用的资源文件。这个开关对 Flutter-Notebook 这类包含大量图片、字体、配置文件的项目很有效——demo 里很多资源可能根本不会被生产代码引用到，直接裁掉能显著减小 APK 体积。但也正因为这个特性，如果你的代码里用了反射，或者资源文件被动态引用（比如通过字符串拼接资源名），就会误删。Flutter 的MethodChannel调用原生方法时不涉及资源反射，但第三方 SDK 可能会，需要格外留心。
2.2 第二步：写一份适合 Flutter 项目的 proguard-rules.pro
proguard-rules.pro是 Android 混淆规则文件，决定哪些类保留、哪些类重命名、哪些类不做混淆处理。Flutter 项目的基础规则大体如下：
# Flutter SDK 相关 -keep class io.flutter.** { *; } -keep class com.example.flutter_notebook.** { *; } # 保持枚举不被混淆 -keepclassmembers enum * { public static **[] values(); public static ** valueOf(java.lang.String); } # 保持注解信息 -keepattributes *Annotation* -keepattributes SourceFile,LineNumberTable -keepattributes JavascriptInterface # JNI 方法 -keepclasseswithmembernames class * { native <methods>; }这里重点说几个容易踩的细节。
第一，io.flutter.**必须保留。Flutter 引擎和框架层的类有许多通过 JNI 与底层交互，JNI 方法是按方法名查找的，混淆后找不到对应 native 方法，直接崩溃。而且 Flutter 引擎本身是 C++ 写的，Java 层的io.flutter.*只是薄封装，混淆它没有任何收益。
第二，com.example.flutter_notebook.**是否需要保留，取决于你的使用方式。如果你只是把 Flutter-Notebook 当作 demo 参考，不打算直接把里面的类作为主工程代码，那么不建议保留——保留意味着这部分类完全暴露，等于白做混淆。但如果是把它作为库模块引入，主工程通过反射或接口回调访问它，那必须保留，否则运行时找不到类。
第三，枚举的特殊性。R8 对枚举有一套自己的处理方式，正常混淆会把枚举变成普通类。绝大多数场景没问题，但如果有 SDK 在运行时检查具体的枚举类型（比如name()和ordinal()的逻辑），就可能导致问题。上面的-keepclassmembers规则是保守做法。
第四，第三方 SDK 的 keep 规则。我遇到过比较典型的是友盟分享、支付宝支付、微信支付这类 SDK。它们各自的官方文档都会给出对应的混淆规则。在 Flutter-Notebook 中集成的第三方插件，如果 release 包崩溃，第一反应就是去查对应原生 SDK 的混淆配置。这些规则别凭感觉写，直接以 SDK 官方最新文档为准。
2.3 第三步：Dart 层的 --obfuscate 与 --split-debug-info
Android 原生层配置好之后，别忘了 Flutter 项目还有一个独立的 Dart 层。Dart 层不开混淆，构建产物里的符号信息照样能暴露大量逻辑。Flutter 提供的混淆参数是--obfuscate，配合--split-debug-info使用。
在工程的android/app/build.gradle中按如下方式配置：
android { // ... flutter { target = "lib/main.dart" // 注意：高版本 Flutter 使用此配置 release { // 混淆 Dart 代码 obfuscate = true // 将符号文件输出到指定目录，用于还原崩溃堆栈 splitDebugInfo = file("/path/to/debug_info") } } }如果是用命令行手动打包，命令是：
flutter build apk --release --obfuscate --split-debug-info=/path/to/debug_info--split-debug-info的作用是把混淆前后的符号映射文件单独存下来。这个目录里的文件，官方说法是"不包含用户机密代码"，只是扮演"密码本"的角色，用于把混淆后的堆栈还原成可读的 Dart 方法名。这个映射文件极其重要，一定要归档保存。没有它，线上崩溃堆栈全是混淆后的无意义符号，排查问题要多花十倍时间。
Dart 混淆的原理是对类名、方法名重写成分支符号，同时在 AOT 快照中移除对应的调试符号。要注意的是，--obfuscate对字符串字面量不做加密，字符串依然明文存储。也就是说，如果 Flutter-Notebook 的某个 demo 里写死了 API Key 或 Base URL，混淆之后这些字符串还是能直接从产物里搜出来。这是很多人的认知盲区。
2.4 一个很容易遗漏的点：assets 与字符串文件
Flutter-Notebook 项目通常带有不少配置文件，比如pubspec.yaml里声明的 assets。Android 构建时会把这些资源文件原样打进 APK。资源文件本身没有混淆概念，如果里面存放了某些业务相关的 JSON 配置、密钥信息等，就直接暴露了。
我的建议是：生产环境不要把任何敏感信息以明文 assets 形式放在 Flutter-Notebook 风格的 demo 目录里。至少要做一层加密，运行时解密后再加载。Flutter 侧可以用一个小插件做加密解压，成本很低。这个细节，能帮你避免相当一部分在 APK 里翻出密钥的低级事故。
3. iOS 侧配置：思路完全不同于 Android，重点在编译优化与符号剥离
3.1 理解 iOS 的保护逻辑：编译优化 + 符号剥离
iOS 的代码保护体系和 Android 有本质区别。Android 的 Java/Kotlin 代码是基于虚拟机的字节码，R8 会对它做整体重写；iOS 的 ObjC/Swift 代码直接编译成机器码，没有"混淆器"这种通用说法，常用的手段是编译优化级别、Strip Symbols、以及 OC 的类名/方法名加密。
Flutter 在 iOS 侧的产物也分两层：Dart AOT 编译的产物（类似 Android 的快照），以及 Runner 工程里的 ObjC/Swift 原生层（主要是AppDelegate、ViewController、以及各个 Flutter 插件的原生实现）。
iOS 侧没有 ProGuard 这种通用逆向成本放大器，因此思路要换成"尽量移除调试信息 + 优化编译产物 + 对敏感字符串加密"。
3.2 Xcode 工程里的关键开关
在我的实践中，iOS 侧需要重点检查这几个配置：
Build Options->Compiler for C/C++/Objective-C：保持默认 Apple Clang。Apple Clang - Code Generation->Optimization Level：Release 模式下选择Fastest, Smallest (-Os)。这个选项会减少代码体积，同时让一部分内联逻辑更难直接阅读。Apple Clang - Code Generation->Strip Linked Product：Release 模式下设为YES。Deployment Processing->Strip Debug Symbols During Copy：设为YES。Strip Style：设为All Symbols。
这些配置的效果是：Release 包中将不再包含符号表，Mach-O 文件体积变小，同时用nm、class-dump这类工具提取信息时，能拿到的有效内容大幅度减少。
还有一项是 Swift 的混淆。如果你的 Runner 工程用了 Swift 原生代码，且对安全需求比较高，可以考虑开启Whole Module Optimization和编译时Optimize for Size。Swift 本身在 Release 下默认做了一些符号私有化处理，但依然没有 Android 层混淆那种杀伤力。需要接受这个现实：iOS 的防护上限比 Android 低，操作重点是"减少能拿到的信息量"。
3.3 字符串加密与防 class-dump
class-dump 针对的是 ObjC 运行时信息。因为 ObjC 的方法调用基于 runtime 的消息机制，方法名、协议、属性在 Mach-O 中会以字符串形式存在。不加密的情况下，class-dump可以还原出几乎完整可读的头文件。
Flutter-Notebook 集成的原生插件中，有相当一部分是 ObjC 写的。这些类的名字、方法签名，在上线后都等于暴露。目前主流的处理方式是对 OC 字符串做编译期加密。方案有很多，比如用宏在编译前把字符串常量拆成多个字节后再重新拼装，或者用一些第三方工具链做 string encrypt。举一个简化示例：
// 一个极简的字符串加密宏，真正的项目里要配合密钥与运行时还原 #define OB_STR(s) [NSString stringWithCString:(const char[]){\ [(s)[0]], [(s)[1]], [(s)[2]], 0} encoding:NSUTF8StringEncoding]这种做法的本意是让敏感字符串不以明文形式出现在二进制中。但它只能拦截直接strings搜索的人，对动态调试 Hook 几乎无解。所以定位是"提高门槛"，不是"彻底隐藏"。
class-dump后头文件暴露的问题，目前没有一键混淆 ObjC 运行时类名的通用工具。商业加固方案会做 ObjC 元数据加密，但那是私有方案。社区能看到的信息，基本都是按项目去定制扫描和替换 OC 类名/方法名的脚本。如果基于 Flutter-Notebook 做二次开发，需要谨慎评估是否值得投入这么高的维护成本。大多数个人项目做到符号剥离和字符串加密这两步，已经能阻挡绝大多数初级逆向者了。
3.4 iOS 上 Dart 混淆的现状与建议
Flutter 官方对 Dart 混淆的支持，Android 和 iOS 在底层机制上是一样的。在 iOS 上同样可以使用--obfuscate --split-debug-info参数：
flutter build ios --release --obfuscate --split-debug-info=/path/to/debug_info但 iOS 上使用这个方案有一个和 Android 不一致的重要差异：iOS 的 App Store 上架时，如果使用了--obfuscate，需要特别关注符号文件的处理。因为 Apple 的崩溃报告系统需要依赖 dSYM 符号文件才能还原崩溃堆栈，而 Flutter 生成的符号映射文件和 dSYM 不是同一个东西。你仍然需要保留完整的 dSYM 并上传到 App Store Connect，否则后台看到的崩溃日志全是十六进制地址。
实测下来，iOS 上开启 Dart 混淆后，即使配置完全正确，依然可能出现个别旧版本 iOS 上启动时间变长、Crash 概率上升的情况。这种问题很难定位。我的建议是：如果你的目标用户 iOS 版本覆盖率较老（iOS 12 以下），先在小流量设备上验证确认可接受，再在 full release 中开启。
4. 配置完成后的验证：看一眼产物，才知道配置到底生效没有
4.1 静态验证：用 strings 和 class-dump 检查产物
很多人在 build.gradle 里改完配置，打了个 release 包，就以为万事大吉。实际上是不是真的混淆成功，得拿产物说话。
对 Android，用 jadx 直接打开 APK，随机看几个类：
jadx -d output_dir your_app.apk如果看到a.a.a、b.b.b这类随机字母的包名类名，说明 R8 的混淆生效了。如果还看到com.example.flutter_notebook.*这样清晰可读的路径，说明 keep 规则写得过于宽泛。同时，用strings搜索一下 APK 里的敏感字符串：
strings your_app.apk | grep -i "api_key\|secret\|password"有输出的话，就意味着字符串还是明文状态，需要做额外加密或避免硬编码。
对 iOS，先拿到 ipa 并解压出 Runner 可执行文件：
nm -gU Runner | head -20如果 Output 里有大量带符号名的 Swift 符号或者较完整的 ObjC 方法名，那就说明符号剥离不彻底。再用class-dump -H Runner -o output_dir还原头文件，观察能提取出多少类信息。正常情况下，开启 Strip Symbols 后能提取到的信息会大幅减少。
4.2 运行期验证：混淆不崩溃才是真正的成功
静态验证只能说明"信息有没有被隐藏"，运行期验证才能说明"混淆之后业务还正不正常"。这一步我通常是分两层跑的。
第一层，跑通 Flutter-Notebook 中所有集成的关键功能。具体来说，我建议至少覆盖：网络请求（HTTP/Dio）、本地数据库（sqflite）、路由导航、MethodChannel 调用、第三方登录/分享、支付流程。如果这些核心路径在 release 包上全部正常，原生层的 keep 规则基本没有问题。
第二层，主动制造一次崩溃，验证堆栈还原能力。在代码里写一个必崩的异常，然后在 release 包上触发它，拿到崩溃日志后用flutter symbolize命令配合之前保存的符号文件还原：
flutter symbolize -i stack_trace.txt -d /path/to/debug_info如果输出的堆栈能还原成可读的 Dart 方法名，说明--split-debug-info的配置正确，线上排查路径就通了。这一层验证非常值得做，因为很多团队配置文件路径写错，等到线上崩溃了才发现堆栈还原不了，那时已经晚了。
4.3 回归测试不能只看功能
配置完混淆之后，除了功能回归，还有一块容易漏：性能。混淆以后的代码会多出一些间接层，Dart 侧--obfuscate会让部分内联方法失效，Android R8 优化也可能改变对象分配时机。这些叠加起来，有可能导致启动时间从 1.2 秒变成 1.8 秒，或者卡顿在低端机上变明显。
我的习惯是：在主流的低端 Android 机（比如骁龙 6 系、天玑 700 档位）和老一代 iPhone（iPhone X 那档）上，分别跑一遍 release 包，关注启动耗时、首帧时间、页面切换帧率这三项。实测数据告诉我，绝大多数掉帧问题就出在没做混淆前的版本和混淆后版本之间的差异。这个回归动作，在 Flutter-Notebook 这种 demo 云集的项目里尤为重要，因为 demo 里的页面往往写得很随性，线上化之后极易暴露性能问题。
5. 常见问题与我的排查经验
5.1 ProGuard/R8 混淆后 Native 层崩溃的排查链路
遇到混淆后 native 崩溃，我的排查顺序是固定的，基本不绕弯路：
第一步，关掉minifyEnabled = false，用同样的源码打一个 release 包，看是否还崩溃。如果不再崩溃，基本确认是混淆规则问题。如果依然崩溃，那就要回看原生代码本身的兼容性，不背混淆的锅。
第二步，重新开启混淆，但只保留最精简的-keep class io.flutter.** { *; }这一条，其他 keep 规则清空，再看是否崩溃。如果恢复，说明是某个第三方 SDK 的 keep 规则缺失。
第三步，定位具体 SDK。二分法最有效：先搜崩溃日志里的类名，在proguard-rules.pro里先写一条最宽的-keep class com.xxx.sdk.** { *; }做验证。等崩溃消失，再根据官方文档把规则收窄。这里有个技巧：收窄规则时优先从"代码里直接引用的类"入手，不要试图用普适规则覆盖所有场景。
5.2 Debug 模式下的"假象"：测试一定要分清构建类型
很多人在开发阶段用的是flutter run，这是 debug 模式，Dart 代码走 JIT，原生代码没有混淆，所有配置都不生效。然后他们用flutter build apk --release打包后直接在命令行启动 App，跑几个用例就宣称"没问题"。
严格来说这不算错，但有一个真实事故值得警惕：我曾经在 debug 模式下跑通了一个方法通道，结果 release 包一启动就挂。原因就是原生方法使用了 reflection 反射调用，release 下 R8 把对应类重命名后，反射找不到了。如果在 debug 模式下反复测试一百遍，结果都一样：通过。这类问题只有 release 模式才能暴露。
所以关于验证坏境的结论很明确：最终验证必须用 release 包，最好用一台支持它的真机。模拟器上跑 release 包，虽然代码和真机一样，但端上环境、传感器、定位、支付模拟都没有参考价值。
5.3 混淆后的维护成本：符号文件的妥善管理
--split-debug-info生成的目录，好比一把钥匙。用它对不上崩溃堆栈，排查事故时会非常被动。
我的做法是：每次发版本，把对应的符号文件目录连同版本号一起归档，放到公司自己的对象存储或者至少打个压缩包存到 CI 的产物区。归档目录结构大致这样：
release_archive/ 1.2.0/ android-debug-info/ ios-debug-info/ Runner.dSYM/ proguard/ 1.2.0_mapping.txtmapping.txt是 Android 的 ProGuard/R8 映射文件，一般在android/app/build/outputs/mapping/release/下。把它和 Dart 符号文件放在一起，出了线上问题才能快速还原。
5.4 应对"混淆后测试人员抱怨某些功能异常"的边界问题
如果小团队没有专职测试，产品经理或外包测试人员会用同一个 App 验证新旧版本，很容易混淆 debug 和 release 的差异。我见过最典型的情况是：release 包里 WebView 的登录态掉了、分享回调不触发、图片加载失败，测试就把问题归到"升级导致"。
这里有个非常实用的排查结论：先检查 release 模式下 Flutter 的网络代理是否正常。因为 release 默认不走系统的代理设置，测试机挂着代理抓包时，release 包显示异常是正常现象。这个问题不做混淆也会出现，但混淆后更隐蔽，容易被误判成代码逻辑被混淆破坏。
5.5 不要过度依赖"全局 keep all"的偷懒写法
有一种非常省事的做法，很多人用来应付 release 崩溃：
-keep class ** { *; }这行规则能让所有类都不混淆，等于完全关闭了 Android 侧的混淆。后果很清楚：APK 体积变大，攻击者一览无余。我虽然理解时间紧迫的情况下它是"让 App 先跑起来"的底线手段，但长期来看，这会让所有配置工作直接报废。
如果确实没时间逐个 SDK 排查 keep 规则，可以按包名范围做局部 keep，优先保释出你依赖第三方 SDK 的包名前缀，剩余自己的业务代码仍保持混淆。这样至少能守住 70% 的保护效果，同时规避 95% 的崩溃风险。
6. 根据 Flutter-Notebook 的使用方式，把配置策略做一次落地
6.1 直接当作生产模板使用的最优策略
如果你计划直接把 Flutter-Notebook 的某个 demo 作为业务模块的起点，我建议按如下顺序操作：
先梳理这个 demo 依赖了哪些 Flutter 插件，去 pub.dev 查每个插件的原生混淆说明，整理成一张对照表。再把proguard-rules.pro按插件分组注释，做到每条规则都有据可查。不建议图省事把所有插件的 keep 规则全部堆上来——规则的暴露面越小，保护效果越好。
Dart 测--obfuscate务必开启。Flutter-Notebook 里的类名包含了大量的业务语义，例如LoginPage、PaymentService、ApiClient这种名称，不混淆的情况下等于给逆向者画好了全套思路。混淆后至少肉眼看上去是随机的。
iOS 侧除了 Strip Symbols 之外，把AppDelegate里涉及 URL Scheme、Universal Link 跳转的部分整理出来，做一次字符串加密。这部分逻辑是最容易被分析者盯上的。
6.2 从演示到生产的"最小改动清单"
如果只想做最小改动，就检查这三项是否到位：
build.gradle里isMinifyEnabled = true、isShrinkResources = true打开。--obfuscate --split-debug-info已配置，并且符号文件有归档。- iOS Release 配置中 Strip Linked Product 和 Strip Debug Symbols During Copy 均为 YES。
这三步做完，大部分常见信息暴露问题可以解决。剩下的是优化级，按需求和时间精力来取舍。
6.3 生产环境的持续维护：每次发版都要带上新符号文件
混淆本质上是一个"每次构建都可能变化"的过程。哪怕你一行源码没改，换了 Flutter SDK 补丁版本，混淆结果都可能不一样。因此符号文件和映射文件必须跟着版本走，而不是手动传到某个固定目录。
比较推荐的做法是在 CI/CD 流水线上加一步：release 构建成功后，自动把debug_info、mapping.txt、dSYM压缩成带版本号的文件，上传到内部存档服务。这样线上出问题时，直接进后台下载对应版本的符号文件，用flutter symbolize把堆栈还原，效率极高且不会出错。
6.4 老版本 Flutter 项目的升级注意事项
Flutter-Notebook 项目和纯 demo 不一样，它有历史包袱：有的示例是早期的 Flutter 版本写的，原生配置旧。升级 Flutter 到较新版本时，混淆配置往往要跟着调整。
比如 Flutter 2.x 时代，--obfuscate之前还需要额外处理--split-debug-info的路径规范；新版 Flutter 已经能在android/app/build.gradle的flutter配置块中直接设置。另一个常见问题是，第三方插件在旧版依赖的是androidx.annotation相关库，新版 Flutter 构建时可能启用了不同的 R8 规则，需要在 release 包里重新验证。
我踩过一次的坑是：升级 Flutter 后，release 包启动报MissingPluginException。排查了半天，最后发现是插件注册目录下的某个 keep 规则在新版 R8 中不再适用，把插件相关的类名在混淆后改掉了，导致 Dart 侧通过 method channel 找不到原生的 plugin 实例。这个问题的根源就是老版本 Flutter 生成的GeneratedPluginRegistrant.kt对混淆的依赖规则变了。遇到类似情况，直接在 release 包上抓日志，定位到 plugin 名，再去查当前 Flutter 版本对应的插件注册规则，比逐行查 keep 规则快得多。
最终我自己的心态是：把混淆和安全配置当成发版流程里的固定成本来对待，而不是"有空再弄"。尤其是在 Flutter-Notebook 这种代码高度可读的示例型项目基础上改业务，前期的安全配置花半天能完成，可以帮后期省下大量查崩溃、防爬、防抄的时间。技术与工具都在更新，但核心原则一直没变——保护好代码的边界，就像保护好应用的用户数据一样，属于产品质量的一部分。
