企业官网建设流程全解析

1. Package不是插件，是Flutter生态的“标准零件库”

刚接触Flutter时，我跟很多开发者一样，把package当成“插件”来用——看到一个功能缺了，就去pub.dev搜个名字带“camera”“pdf”“local_notification”的包，flutter pub add一下，照着README调几个API，能跑通就完事。直到某次在某跨平台系统重构中，团队因为三个不同package对同一套SQLite底层做了三套封装，导致数据库锁死、事务冲突、iOS上偶发崩溃，才真正意识到：Package不是拿来即用的黑盒工具，而是Flutter工程里需要被主动设计、评估和管理的标准化零件。它直接决定项目长期可维护性、构建稳定性、甚至上线后的用户留存率。

Package在Flutter里有明确定义：它是遵循Dart语言规范、通过pubspec.yaml声明元信息、支持flutter pub get统一拉取、具备版本语义化（SemVer）约束、可被其他package或应用依赖的代码集合。它不等于“第三方库”，也不等同于“原生模块”。比如httppackage本身不包含任何Android/iOS原生代码，纯Dart实现；而path_provider则必须桥接原生平台获取文档目录路径——但二者都叫package，因为它们共享同一套分发、依赖、缓存机制。这种统一性，正是Flutter区别于React Native或原生开发的关键基建能力。

你可能正在面临这些典型场景：

• 新人接手老项目，发现pubspec.yaml里混着20多个package，其中5个已弃用，3个存在已知安全漏洞，但没人敢删——因为不知道谁在用、怎么用的；
• App体积突然暴涨30MB，排查发现是某个UI组件库偷偷引入了整套image_picker+video_player+ffmpeg_kit，而你只用了它的一个圆角裁剪小功能；
• CI流水线频繁失败，日志显示pub get超时或校验失败，但本地一切正常——本质是未锁定依赖版本，不同机器拉取了不同快照；
• 某个支付功能在Android上稳定，在iOS上偶发白屏，最后定位到是flutter_paystack4.2.1版与shared_preferences2.2.0存在隐式类型转换冲突，但错误堆栈根本没暴露这个关联。

这些问题，没有一个靠“换个包”能根治。它们暴露的是对Package机制理解的断层：我们熟练调用setState()，却说不清pubspec.lock里一行哈希值的意义；我们能手写复杂动画，却不敢动dependency_overrides配置。这篇内容，就是帮你把Package从“调用对象”变成“设计元素”——就像机械工程师不会只关心螺丝能不能拧紧，更要懂螺纹规格、材料强度、预紧力计算。接下来所有内容，都基于真实项目踩坑记录展开，不讲虚概念，只给可验证、可复现、可审计的操作逻辑。

2. Package设计底层逻辑：为什么Pub.dev不是App Store

2.1 Pub.dev的本质是“源码分发协议”，不是应用市场

很多人误以为pub.dev是Flutter的“应用商店”，点开就能下载安装。这是根本性误解。Pub.dev是一个基于Git协议的源码托管与元数据索引服务。当你执行flutter pub add http，实际发生的是：

1. Flutter CLI读取pubspec.yaml，确认当前SDK约束（如sdk: ">=3.0.0 <4.0.0"）；
2. 向pub.dev API发起请求，查询http最新兼容版本（假设返回^1.1.0）；
3. 从https://pub.dev/packages/http/versions/1.1.0.tar.gz下载压缩包（非二进制，是Dart源码+资源文件）；
4. 解压到<project>/.dart_tool/pub/cache/，并生成pubspec.lock记录精确版本与校验和；
5. 最后修改pubspec.yaml，添加http: ^1.1.0行。

关键点在于：所有package代码最终都会编译进你的App产物中，不存在运行时动态加载。这与iOS的Framework、Android的AAR有本质区别——后者可独立更新，前者一旦打包就固化。所以Package选择不是“功能够用就行”，而是“这段代码未来三年是否值得我维护”。

我曾参与一个医疗类App的合规改造，要求所有第三方代码必须通过静态扫描。当审计工具报出crypto: 3.0.2存在已知CVE时，团队第一反应是“升级到3.0.3”。但实际检查发现：3.0.3只是修复了一个文档错字，真正的漏洞修复在3.1.0，而3.1.0要求Dart SDK >=3.2.0，但项目因兼容旧设备仍锁定在3.1.0。最终方案是：手动forkcrypto仓库，cherry-pick漏洞补丁，发布私有版本crypto_forked: 3.0.2+patch1，并在pubspec.yaml中用git依赖指向该仓库。这个操作在App Store绝对不可行，但在Pub.dev体系下是标准流程。

2.2 版本号不是数字，是契约承诺

^1.2.3、~1.2.3、>=1.2.0 <2.0.0这些符号，绝非随意约定。它们是Dart Package Manager强制执行的语义化版本（SemVer）契约，直接关联代码变更风险等级：

某次紧急热修中，团队将provider从6.0.5升级到6.1.0，仅改了次要版本号。但6.1.0悄悄将ChangeNotifierProvider的create参数从Create<T>改为Create<T?>，导致所有未显式标注空安全的Provider初始化崩溃。问题根源不在代码，而在对^6.0.5的理解偏差——它允许6.1.0，但6.1.0的变更超出了“次要版本应向后兼容”的SemVer原则。后来我们强制所有核心package使用~锁定，配合pub outdated --mode=null-safety每日扫描，将此类风险降低90%。

2.3 依赖图不是树，是网状信任链

pub deps命令输出的依赖树，常被当作“谁依赖谁”的简单关系。但真实情况复杂得多：

• 传递依赖冲突：A包依赖json_serializable: ^6.7.0，B包依赖json_serializable: ^7.0.0，而7.0.0移除了part文件生成器。此时flutter pub get会报错，除非你手动dependency_overrides指定一个双方都能接受的版本；
• 平台特定依赖：flutter_svg在iOS上依赖xml包解析SVG，Android上却用android.graphics原生渲染，同一package在不同平台走完全不同的代码路径；
• 隐式全局状态污染：get_it和riverpod都提供服务定位，但若同时引入且未隔离作用域，get_it.registerSingleton()注册的实例可能被ref.watch()意外捕获，造成状态混乱。

我们在某教育App中遇到过经典案例：firebase_core2.15.0 与cloud_firestore3.4.8 共存时，firebase_core内部的FirebaseApp.configure()调用会覆盖cloud_firestore的Firestore.instance.settings()配置，导致离线缓存失效。根本原因不是版本不匹配，而是两个package共享了FirebaseApp单例，但未约定配置优先级。解决方案不是降级，而是用dependency_overrides强制统一firebase_core为2.14.0，并编写单元测试验证Firestore.settings().persistenceEnabled始终为true。

3. Package选型实战：从“能用”到“敢用”的四步法

3.1 第一步：用pub outdated做健康快筛（5分钟）

别急着写代码，先让CLI告诉你项目现状。在终端执行：

flutter pub outdated --mode=null-safety --prereleases

关键参数解读：

• --mode=null-safety：只显示已迁移空安全的版本，避免引入非空安全代码污染整个项目；
• --prereleases：显示预发布版（如1.2.0-dev.1），用于评估新特性但不建议生产使用。

重点关注三列：

• Resolvable：当前可升级到的最高兼容版本（绿色表示安全）；
• Upgradable：需修改pubspec.yaml才能升级的版本（黄色警告）；
• Available：最新发布版（红色高亮，可能含breaking change）。

实操心得：我们给每个新成员配了自动化脚本，每天早会前运行此命令，将结果导出为Markdown表格，按“高危（需72小时内处理）”、“中危（本周内处理）”、“低危（迭代规划）”分级。例如某次扫描发现http从0.15.4升至1.1.0，Resolvable列为1.0.4，说明1.0.4是当前SDK下最稳版本。跳过1.1.0不是保守，而是1.1.0要求Dart 3.0，而项目尚未完成Dart 3迁移。

提示：pub outdated默认只检查直接依赖。要扫描全量依赖（含传递依赖），加--transitive参数，但输出会剧增，建议先聚焦直接依赖。

3.2 第二步：用pub upgrade --major-versions做深度清理（15分钟）

当项目迭代半年后，pubspec.yaml常积累大量过时依赖。手动一个个升级效率低且易漏。执行：

flutter pub upgrade --major-versions

此命令会尝试将所有依赖升级到最新主版本（如2.x.x→3.x.x），并自动解决冲突。但它不是万能钥匙——它可能升级出一堆编译错误。

正确姿势是：

1. 先备份pubspec.lock：cp pubspec.lock pubspec.lock.backup；
2. 运行flutter pub upgrade --major-versions；
3. 若失败，用git checkout -- pubspec.lock回退，再针对性升级单个包：flutter pub upgrade http；
4. 成功后，立即运行flutter pub run build_runner build --delete-conflicting-outputs（若用build_runner）。

我们曾用此法将某电商App的provider从5.0.0升至6.1.2，耗时22分钟。关键技巧是：升级前先搜索providerGitHub Issues，筛选6.0.0-breaking-changes标签，提前知晓Provider.of<T>(context)需改为context.watch<T>()，避免在IDE里大海捞针。

3.3 第三步：用pub publish --dry-run做私有包审计（30分钟）

即使不用发布，pub publish --dry-run也是最强Package体检工具。它会模拟发布流程，强制检查：

• pubspec.yaml是否符合规范（如description长度≥10字符，homepage格式正确）；
• 是否存在未声明的dev_dependencies被误用（如test包里的expect()在lib/代码中调用）；
• LICENSE文件是否存在且内容合法；
• lib/目录下是否有未导出的_private.dart文件被意外引用。

在某金融类SDK开发中，我们执行--dry-run时被拦截：lib/src/utils/crypto_helper.dart被lib/main.dart导入，但main.dart未在pubspec.yaml的exports中声明。这意味着外部项目无法安全使用该工具类——它属于内部实现细节。解决方案是：将crypto_helper.dart移入lib/src/子目录，并确保lib/下只有my_finance_sdk.dart一个入口文件，通过export 'src/utils/crypto_helper.dart';显式暴露必要接口。

注意：--dry-run会检查README.md中的链接有效性。我们曾因此发现文档里一个指向已删除GitHub Wiki的链接，及时修复避免了客户集成时的困惑。

3.4 第四步：用pub.dev页面做可信度交叉验证（20分钟）

别只看Stars数！真实评估一个Package，要查四个关键页：

1. Scores页：看“Health"分（代码质量）、"Maintenance"分（更新频率）、"Popularity"分（下载量）。健康分<80分的包，慎用；
2. Changelog页：重点看最近3次更新日志。若全是Update README、Fix typo，说明维护停滞；若每次更新都明确列出breaking change和迁移指南，说明作者专业；
3. Repository页：点开GitHub链接，看Issues列表。若大量help wanted且无人响应，或PR积压超50个，风险极高；
4. Versions页：向下滚动，看历史版本发布时间。若1.0.0发布于2020年，2.0.0在2023年才出，中间三年无更新，基本可放弃。

我们曾淘汰flutter_local_notifications的某个竞品包，就因它的Changelog里写着v1.2.0 - Fix crash on Android 12，但Repository的Issues中，Android 12用户仍在抱怨同样崩溃，且作者回复“请升级到v1.3.0”，而v1.3.0根本不存在。这种信号比任何评分都真实。

4. Package管理避坑指南：那些文档里不会写的血泪经验

4.1pubspec.lock不是可选文件，是法律合同

很多团队把pubspec.lock加入.gitignore，理由是“不同环境依赖可能不同”。这是重大误区。pubspec.lock的作用是：锁定整个依赖图的精确版本与校验和，确保任意机器、任意时间flutter pub get拉取的代码100%一致。

我们吃过亏：某次发布前，CI服务器拉取的path_provider是2.1.1，而开发机本地是2.1.0。2.1.1修复了一个iOS路径编码bug，但2.1.0在特定路径下返回null，导致App启动白屏。因pubspec.lock未提交，问题只在CI暴露，本地无法复现。

正确做法：

• 必须提交pubspec.lock到Git，且禁止手动编辑；
• CI流程第一步必须是flutter pub get，而非跳过；
• 若需临时覆盖，用dependency_overrides并在pubspec.yaml顶部加注释说明原因及预计恢复时间。

提示：pubspec.lock文件很大？那是你没启用Git LFS。用git lfs track "pubspec.lock"将其纳入大文件追踪，既保一致性又不拖慢Git。

4.2dependency_overrides不是急救包，是手术刀

dependency_overrides常被当作“解决冲突的万能膏药”。但滥用会导致：

• 本地能跑，CI失败（因override未生效）；
• 升级时忘记移除override，导致长期使用过时版本；
• 多个override相互干扰，形成隐式依赖链。

我们的标准流程：

1. 仅在pubspec.yaml顶部name:下方添加dependency_overrides块；
2. 每行override必须带#注释，说明：
   • 冲突原因（如# Conflict: firebase_core 2.15.0 requires cloud_firestore 3.4.8, but we need 3.5.0 for offline persistence）；
   • 预计解决时间（如# TODO: Remove after firebase_core 2.16.0 release (ETA: 2024-Q3)）；
3. 每周用grep -n "dependency_overrides" pubspec.yaml检查所有override，评估是否可移除。

某次我们为解决flutter_svg与cached_network_image的xml版本冲突，override了xml: 6.3.0。三个月后，flutter_svg官方适配了xml 6.4.0，但我们忘了移除override，导致xml 6.3.0的安全漏洞（CVE-2023-XXXXX）未被修复。现在所有override都关联Jira任务，到期自动提醒。

4.3 私有Package不是“放自己服务器”，而是“建可信镜像”

很多团队建私有Pub服务器（如pub.dev的私有部署版），以为能解决安全审计。但实际运维成本极高：同步上游、处理证书、权限管理、备份恢复。更优解是：用Git Submodule或Git URL依赖，将私有Package作为代码仓库直接嵌入项目。

例如，某支付SDK被拆为payment_core（通用逻辑）和payment_alipay（支付宝适配）。我们不发布payment_core到私有Pub，而是：

dependencies: payment_core: git: url: https://gitlab.example.com/payment/payment_core.git ref: v1.2.0

优势：

• 代码可见、可审计、可调试（IDE直接跳转到Git仓库源码）；
• 版本即Git Tag，无需维护额外版本号；
• 团队成员克隆项目即获得完整依赖，无网络依赖。

唯一注意点：确保Git仓库的pubspec.yaml中publish_to: none，避免误发布到pub.dev。

4.4dev_dependencies不是“开发时用”，而是“构建时注入”

dev_dependencies常被误解为“只在flutter test时加载”。实际上，它参与整个构建流程：

• build_runner、json_serializable等代码生成工具，在flutter pub run build_runner build时执行；
• flutter_launcher_icons在flutter pub run flutter_launcher_icons:main时修改原生资源；
• mocktail在flutter test时替换真实依赖。

关键陷阱：dev_dependencies中的包，其lib/代码不能被lib/主代码直接import。否则flutter build apk会报错Target of URI doesn't exist。

我们曾因lib/utils/logger.dart里写了import 'package:mocktail/mocktail.dart';，导致Release构建失败。修复方案是：将Logger抽象为接口，lib/src/logger_impl.dart实现，test/目录下用mocktail实现MockLogger，主代码只依赖接口。

常见误用清单：

• 在lib/中importtest、mocktail、build_runner；
• 在lib/中调用testWidgets、verify等测试专用函数；
• 将dev_dependencies版本写在dependencies块下。

5. Package性能优化：从“能跑”到“丝滑”的硬核实践

5.1 构建速度瓶颈：pub get不是网络问题，是IO争抢

flutter pub get慢，90%不是网速问题，而是磁盘IO争抢。pub cache默认在~/.pub-cache，若该目录在机械硬盘或共享网络盘，pub get会卡在解压阶段。

实测数据：同一项目，在SSD上pub get平均2.3秒，在HDD上达18.7秒。优化方案：

• 重定向cache目录到SSD：export PUB_CACHE="/path/to/ssd/.pub-cache"（macOS/Linux）或set PUB_CACHE=C:\ssd\.pub-cache（Windows）；
• 启用并发下载：在~/.dart/config中添加concurrent-downloads: 10（默认3）；
• 禁用校验（仅开发环境）：flutter pub get --no-precompile，跳过Dart文件预编译。

我们给所有MacBook Pro配了PUB_CACHE环境变量，CI服务器则用--cache参数指定RAM Disk路径（/dev/shm/.pub-cache），构建时间下降40%。

5.2 包体积膨胀：tree_shaking失效的三大元凶

Flutter的Tree Shaking本应自动移除未用代码，但Package常破坏这一机制：

1. 反射调用：json_serializable生成的_$MyClassFromJson函数，因通过Function.apply()动态调用，无法被Shake；
2. 条件导入：if (kIsWeb) import 'web_impl.dart';中，web_impl.dart即使不运行也会被打包；
3. 全局单例注册：get_it中registerSingleton<ApiService>(ApiService())，即使ApiService未被调用，其实例化代码仍保留。

解决方案：

• 对json_serializable，用@JsonSerializable(explicitToJson: true)强制显式序列化，减少反射；
• 条件导入改用export+ 平台判断：在lib/platform.dart中export 'src/platform_web.dart' if (dart.library.html) else 'src/platform_mobile.dart';；
• 全局注册改用懒加载：get_it.registerLazySingleton<ApiService>(() => ApiService());。

某新闻App通过此法，将flutter build apk --release产物从42MB降至28MB，APK Analyser显示libflutter.so外的Dart代码减少11MB。

5.3 运行时卡顿：Package的“隐藏帧耗”

很多Package在initState()或build()中执行耗时操作，却不暴露控制开关。例如：

• cached_network_image默认开启progressIndicatorBuilder，每次图片加载都重建Widget树；
• flutter_svg解析复杂SVG时，主线程阻塞超16ms，导致掉帧。

诊断方法：在DevTools中开启CPU Profiler，录制10秒操作，过滤package:关键词，查看耗时Top 5的Dart函数。

优化实录：

• 对cached_network_image，禁用进度指示器：placeholder: (context, url) => Container()；
• 对flutter_svg，预加载SVG：final svg = await SvgPicture.svgStringDecoder('...');，在initState()中解析，build()只负责渲染；
• 自定义ImageProvider，对网络图片加resize参数，避免在UI线程缩放。

我们曾用此法将某电商首页的FPS从42提升至59，Raster线程耗时从22ms降至8ms。

5.4 热重载失效：Package的“状态污染”陷阱

热重载失败常归咎于IDE，实则是Package持有不可热重载的状态。典型案例如：

• provider中ChangeNotifier继承自Listenable，其addListener()注册的回调在热重载后未清除；
• hive数据库打开的Box实例，在热重载后仍指向旧内存地址。

解决方案：

• 使用flutter run --hot-reload-rollback（Flutter 3.16+），自动回滚失败的热重载；
• 在dispose()中显式清理：_box.close()、_controller.removeListener(_onChanged)；
• 对provider，用AutoDisposeProvider替代Provider，生命周期自动绑定Widget。

某教育App接入riverpod后，热重载成功率从63%升至98%，关键改动是将所有Provider替换为AutoDisposeProvider，并确保ref.watch()只在build()中调用。

6. Package安全审计：从“信任作者”到“验证代码”

6.1 静态扫描：用dart analyze揪出隐藏风险

flutter analyze默认只检查语法，但dart analyze可深度扫描。在项目根目录执行：

dart analyze --fatal-infos --fatal-warnings --format=machine lib/

关键参数：

• --fatal-infos：将INFO级提示（如unused_import）视为错误；
• --fatal-warnings：将WARNING（如deprecated_member_use）视为错误；
• --format=machine：输出JSON，便于CI解析。

我们配置了CI流水线，若扫描出任何ERROR，立即中断构建。曾因此拦截一个严重问题：lib/auth/login_service.dart中，await _apiClient.post('/login', body: credentials)未包裹try/catch，而_apiClient来自httppackage。dart analyze标记为unawaited_futures，提示“Future未等待，异常将被静默丢弃”。补上try/catch后，登录失败时能准确上报错误码。

6.2 依赖溯源：用pub deps --json构建信任图谱

pub deps --json输出完整的依赖关系JSON。我们用Python脚本解析，生成三类报告：

• 供应链深度报告：统计每个package的传递依赖层数，超过5层的标红（如flutter_svg→xml→collection→meta→sky_engine）；
• 许可冲突报告：提取所有LICENSE文件，检查是否含GPL等传染性协议；
• 作者重叠报告：统计同一作者维护的package数量，若某作者维护12个package且全部被项目依赖，则该作者离职将成单点故障。

某次审计发现，项目依赖的flutter_bloc、hydrated_bloc、equatable均由同一作者维护。我们立即fork所有仓库，将关键分支同步到公司GitLab，并培训两名成员掌握维护流程，消除单点风险。

6.3 动态监控：用flutter run --profile捕获运行时异常

静态扫描无法发现运行时Package冲突。我们用flutter run --profile启动App，连接DevTools，在Logging面板中过滤package:，重点关注：

• MissingPluginException：Platform Channel未注册，常见于flutter_downloader等原生集成包；
• NoSuchMethodError：Dart类型不匹配，如int传给期望num的参数；
• OutOfMemoryError：image_picker加载大图未压缩。

实操技巧：在main.dart中添加全局错误捕获：

void main() { FlutterError.onError = (details) { if (details.stack.toString().contains('package:')) { // 上报到Sentry，附带package名与版本 Sentry.captureException(details.exception, stackTrace: details.stack); } }; runApp(const MyApp()); }

某社交App通过此法，发现video_player2.4.0在iOS 15.4上因AVPlayerItem内存泄漏导致OOM，及时降级到2.3.0。

6.4 合规兜底：建立Package“白名单+黑名单”双控机制

技术手段总有盲区，必须加管理流程。我们推行：

• 白名单：pubspec.yaml中只允许出现经安全团队审核的package，新引入需提交Package Review Form，含：
  • GitHub Stars & Forks数；
  • 最近3个月Commit频率；
  • 已知CVE列表（查NVD数据库）；
  • 许可证类型（MIT/Apache-2.0优先，GPL禁止）；
• 黑名单：自动扫描pubspec.yaml，若出现blacklisted_packages.txt中的条目（如flutter_crashlytics因隐私政策下架），CI立即失败。

表：白名单审批关键指标阈值

这套机制上线后，新引入Package的平均审批时间从3天缩短至4小时，安全漏洞引入率降为0。

7. Package演进路线：从“用好”到“造好”的能力跃迁

7.1 何时该自己造Package？三个不可外包的临界点

不是所有需求都该找现成Package。当出现以下任一情况，就是自研Package的信号：

1. 业务耦合过深：某电商App的“智能比价”功能，需实时抓取竞品价格、计算差价、生成话术。现有web_scraper包无法满足反爬策略，且每次更新都需重写XPath规则。我们封装为price_comparator，将XPath规则、代理池、重试逻辑全部内置，对外只暴露compare(String sku)方法；
2. 性能要求极致：某AR测量App需每秒处理30帧摄像头流，camerapackage的ImageStream延迟超80ms。我们用platform_channel直连原生Camera API，自研ar_measure_core，延迟压至12ms；
3. 合规红线明确：某金融App要求所有网络请求必须经公司网关签名，而http包无法插入签名逻辑。我们开发secure_http，在BaseRequest中强制添加X-Signature头，并集成国密SM2算法。

决策树：

• 问自己：“这个功能，未来三年是否会被其他5个以上业务复用？” → 否：写业务代码；是：造Package；
• 问团队：“现有Package的Issue列表中，是否有3个以上与我们需求强相关且2个月未解决？” → 是：自研；否：继续观察；
• 问法务：“该Package许可证是否允许修改源码并闭源分发？” → 否：禁止使用。

7.2 自研Package的最小可行结构（MVP）

别一上来就写100个文件。一个可交付的Package，只需5个文件：

1. pubspec.yaml：声明名称、版本、SDK约束、作者；
2. lib/<package_name>.dart：唯一入口文件，export 'src/core.dart';；
3. lib/src/core.dart：核心逻辑，含class MyService和MyService.instance单例；
4. test/core_test.dart：3个核心用例，覆盖正常流、异常流、边界流；
5. README.md：一句话描述、安装命令、3行代码示例、许可证声明。

我们所有内部Package都用此模板，新成员2小时内即可上手。某次为解决shared_preferences在多进程下的数据不一致，我们3小时产出multi_process_prefs，含完整测试，当天就集成到支付模块。

7.3 发布前的终极 checklist（10项必做）

在pub publish前，逐项核对：

1. [ ]pubspec.yaml中version符合SemVer，且description≥10字符；
2. [ ]lib/下无_private.dart文件，所有src/文件均被lib/<name>.dart显式export；
3. [ ]test/目录有<name>_test.dart，且flutter test通过率100%；
4. [ ]README.md含Example代码块，可直接复制运行；
5. [ ]LICENSE文件存在，内容为完整MIT或Apache-2.0文本；
6. [ ]dart format .格式化全部Dart文件；
7. [ ]dart analyze --fatal-infos --fatal-warnings .无ERROR；
8. [ ]dart doc能成功生成文档，无undefined reference警告；
9. [ ]pub publish --dry-run通过，无WARNINGS；
10. [ ] GitHub仓库设为Public，且pubspec.yaml中repository字段指向该URL。

我们曾因第7项失败而拦截一次发布：dart analyze报avoid_redundant_argument_values，指出MyWidget(key: key)中key参数冗余。修复后，代码更简洁，也避免了未来重构时的歧义。

7.4 维护Package的黄金节奏

发布不是终点，而是维护起点。我们定下铁律：

• 每周一上午：运行pub outdated，升级所有Resolvable版本，提交PR；
• 每月1日：检查GitHub Issues，关闭已解决的，对新Issue分类（Bug/Feature/Question）；
• 每季度末：发布x.y.0版本，合并所有Breaking Change，并更新CHANGELOG.md；
• 每年1月：评估Dart SDK兼容性，如Dart 3.0发布后，1个月内完成迁移并发布v2.0.0。

某次flutter_riverpod发布3.0.0，我们提前2周收到通知邮件，立即启动迁移，1周内完成全量测试，新版本上线当天即同步更新。这种节奏，让团队对Package演进从“被动应对”变为“主动掌控”。

我在实际维护data_sync_core这个内部Package时发现，坚持每周升级，比攒3个月一起升，节省的调试时间多出7倍。因为小版本变更的上下文清晰，而大版本升级常需重读整个Changelog。Package不是写完就扔的代码