鸿蒙百篇系列第 80 篇 · 专家 从第 71 篇到第 79 篇，我们走完了"专家架构"阶段。加上前面的 70 篇，100 篇系列已经完成 80%。这篇做两件事：回顾 71-79 篇的内容脉络，梳理前 80 篇的完整知识图谱，并预告最后 20 篇的方向。 一、71-79 篇回顾 文章索引
鸿蒙百篇系列第 79 篇 · 专家 第 12 篇讲过安全机制与权限管理，第 33 篇讲过安全加固。这篇站在安全审计的角度，系统梳理鸿蒙应用在上线前需要做的安全检查和合规对照。 安全不是加一个混淆就完了的事。HarmonyOS NEXT 的星盾安全架构从系统层提供了能力，但开发者如果不知道该用哪些、怎
鸿蒙百篇系列第 78 篇 · 专家 第 37 篇讲过 CI/CD，第 45 篇讲过测试，第 77 篇讲过设计模式。这篇聚焦一个更现实的问题：当鸿蒙团队从 3 人扩展到 10 人、20 人，怎么保证代码质量和协作效率。 小团队靠口口相传，大团队靠规范和流程。这不是形式主义——当你同时有 5 个开发者在
鸿蒙百篇系列第 77 篇 · 专家 第 50 篇讲过设计模式在鸿蒙里的基础应用。到第 76 篇为止，你已经看过分层架构、错误体系、性能治理、热修复、跨平台工程等专家级实践。这篇把它们串起来——站在架构层面，系统梳理 ArkTS/ArkUI 中设计模式的选型与落地。 设计模式不是背出来的，是被代码量逼
鸿蒙百篇系列第 76 篇 · 专家 第 18 篇讲过 ArkUI-X 的基本概念，第 49 篇讲过 H5 容器化。这篇站在架构选型的角度，讲清楚一个现实问题：团队同时要出 Android、iOS、鸿蒙三个端的 App，怎么组织代码。 这不是"哪个框架更好"的问题。不同团队、不同业务、不同历史包袱，答
鸿蒙百篇系列第 75 篇 · 专家 第 74 篇讲了灰度发布。灰度能控制风险，但有一个限制：发现问题到修复版本上架，走 AGC 审核至少要一两天。有些 Bug 等不起——闪退率超过 1%、支付页面打不开、核心功能不可用。这时候需要的是"不发版就修好"。 鸿蒙不支持传统意义上的"热修复"（替换已编译的
鸿蒙百篇系列第 74 篇 · 专家 第 20 篇讲过应用上架流程，第 37 篇讲过企业级 CI/CD。那些讲的是"怎么把应用发出去"。这篇讲的是"怎么安全地发出去"——特别是大版本、大改动时，怎么控制风险。 灰度发布不是"把版本传上去等着"。它是一套完整的版本治理策略：从版本规划、分阶段投放、数据监
鸿蒙百篇系列第 73 篇 · 专家 第 8 篇讲过性能优化的三大战役，第 31 篇讲过 Profiler 工具链，第 57 篇讲过内存分析。这些是"发现问题"的能力。到了专家架构阶段，你要解决的是另一个问题：怎么把发现、归因、修复、验证串成一个持续运转的闭环，而不是每次发版前临时抱佛脚。 性能治理系
鸿蒙百篇系列第 72 篇 · 专家 第 71 篇讲了分层架构。分层之后第一个痛点就来了：底层出了错，怎么把错误干净地传到 UI 层，还不丢上下文？这篇专门讲错误体系的工程化设计。 鸿蒙的 ArkTS 有 try-catch，有 BusinessError，有 errorManager 全局监听，有
鸿蒙百篇系列第 71 篇 · 专家 第 10 篇讲过架构设计的模块化思路，第 34 篇讲过组件化拆分。到第 70 篇为止，你已经掌握了从渲染管线到系统服务的底层知识。从这篇开始，我们进入"专家架构"阶段——把这些底层能力用工程化的方式组织起来，解决大型鸿蒙应用的分层问题。 一个鸿蒙应用从 Demo
