先交代一下写法：这是我整理教材和公开备考资料后的复习笔记，不是"我考过了来传经"。我没有亲历这场考试，所以不会说"我考了多少分"，只会告诉你"我整理后觉得哪些必须背、哪些容易踩坑"。知识点尽量准确，但考试以官方大纲、教材和公告为准，本文里凡是我没查实的地方都会明说。
0. 先看考情：这一篇为什么排在最前面
综合知识是 75 道单选、75 分、45 分及格（教材与多个培训机构资料口径一致：三科各 75 分，各 45 分合格，需一次通过）。综合知识和案例分析连考，合计 240 分钟，综合知识最长 150 分钟，论文另考 120 分钟。这几条我在多个来源里看到的是一致的，具体到你所在省份的报名和考试日期，请看官方公告。
关于 2026 年的日程，我查到的资料有分歧：广州市人社局发布的 2026 年度报考热点问答写的是上半年 5 月 23 日至 26 日、下半年 10 月 24 日至 27 日，且上半年高级科目含系统架构设计师；而某个人博客写的下半年是 11 月 7–8 日，与官方口径对不上。我以广州市人社局的口径为准，但还是那句话，请以中国计算机技术职业资格网和你所在省市考试院的公告为准。教材依据方面，我查到的公开资料显示，官方教材为《系统架构设计师教程（第 2 版）》（2022 年底出版），并配有考试大纲（第 2 版）；网上也有"第 3 版"的说法，但我没有查到官方来源，因此不作断言。
再看分布。希赛网整理的综合知识分值分布大致是：软件架构设计约 19–28 题，软件工程约 9–21 题，两者加起来占了一半以上；系统安全性设计 3–7 题，项目管理 1–4 题，可靠性分析 0–3 题，专业英语 5 题左右。也有个人整理指出近年数据库题里 NoSQL 出现得比关系数据库多。这些都是"大致区间"，不是官方承诺，你拿来定复习优先级就好，别当预测。
一句话备忘：综合知识 = 架构（风格、质量属性、评估、视图）+ 软件工程（模型、需求、测试、维护、设计模式）拿下半壁江山，剩下的数据库、网络安全、新技术放到下篇。
1. 本篇知识框架图
下面这张图是我给自己画的"上篇地图"，六大块，各自对应后文的一节。看图记框架，看表背细节。
2. 软件架构风格
2.1 什么是架构风格
架构风格描述的是一类系统的组织方式：有哪些构件、连接件、拓扑与约束。它比设计模式高一个层次，你可以理解为"系统级的模式"。教材把经典风格分为五大类：数据流风格、调用/返回风格、独立构件风格、虚拟机风格、仓库风格。考试里常直接问"某场景适合哪种风格"，或者给你一段描述让你判断风格名称。
2.2 五大类速查
| 大类 | 典型子风格 | 核心特征 | 典型场景 | 优缺点 |
|---|---|---|---|---|
| 数据流 | 批处理序列；管道-过滤器 | 数据依次流经各处理单元，过滤器独立、只通过管道通信 | 编译器、信号处理、ETL、Unix 命令 | 易复用与并行；不适合交互，数据格式需统一，错误处理难 |
| 调用/返回 | 主程序/子程序；面向对象；层次结构；客户端/服务器 | 控制权按调用关系传递，上下层依赖明确 | 传统 MIS、企业应用、操作系统内核 | 层次清晰易替换；层多则性能下降，上层难感知底层变化 |
| 独立构件 | 通信进程；事件系统（隐式调用） | 构件相互独立，通过消息或事件通信，发布者不知订阅者 | GUI、消息队列、事件总线、发布订阅 | 松耦合、易扩展；执行顺序难预测，调试困难 |
| 虚拟机 | 解释器；规则系统 | 在真实机器上模拟一台"虚拟"机器 | 脚本语言、JVM、专家系统 | 可移植、灵活；解释执行效率低 |
| 仓库 | 数据库系统；超文本系统；黑板系统 | 以共享数据存储为中心，多个构件围绕它读写 | 语音识别、信号解释、IDE、知识库 | 数据集中共享；仓库成为瓶颈与单点 |
关于黑板系统我多说一句：它有三部分——知识源（各自解决问题的一小块）、黑板（共享数据结构）、控制（选择激活哪个知识源）。经典例子是语音识别、图像理解这类"没有确定算法、靠多个专家协作逐步逼近"的问题。看到"多个专家、共享数据、没有固定解题顺序"，就别犹豫了。
2.3 层次、C/S、B/S 与 MVC
- 分层架构：表示层、业务逻辑层、数据访问层、数据层是最常见的四层。每层只依赖下一层（严格分层）或所有下层（松散分层）。好处是隔离变化、职责清晰；代价是性能损耗、级联修改。
- 两层 C/S：胖客户端，客户端承担业务，升级和维护要装客户端；三层 C/S：表示层、功能层、数据层分离，可伸缩性好；B/S：浏览器作为通用客户端，可以看作三层 C/S 的特例，部署维护方便。
- MVC：模型-视图-控制器，控制器接收输入、调度模型，视图负责展示，模型封装数据与业务。MVP 中视图与模型完全隔离，Presenter 居中；MVVM 引入数据绑定，视图和视图模型双向同步。
2.4 C2、事件驱动、微服务、管道与黑板对比
题目里最爱考的是"给你 5 种风格，你选哪个"。我把几种现代和经典风格放在一个表里做对比：
| 风格 | 一眼认出的关键词 | 耦合方式 | 适合 | 不适合 |
|---|---|---|---|---|
| 分层 | 上层依赖下层、每层职责单一 | 层间接口 | 业务系统、网络协议栈 | 对性能极端敏感的场景 |
| 管道-过滤器 | 数据流、过滤器、管道 | 数据格式 | 批量转换、编译器 | 强交互 GUI |
| 事件驱动（发布订阅） | 事件、隐式调用、总线、订阅 | 事件契约 | 异步解耦、实时响应 | 需要严格顺序与强一致 |
| 黑板 | 知识源、共享黑板、无确定算法 | 共享数据 | 语音/图像识别 | 有确定算法的问题 |
| C2 | 构件与连接件、顶部底部端口、请求向上通知向下 | 消息通信 | GUI 软件、可动态替换构件的系统 | 需要构件间直接调用的系统 |
| 微服务 | 独立部署、按业务拆分、去中心化数据、轻量通信 | HTTP/RPC/消息 | 大型、多团队、快速迭代 | 小团队小系统、强事务一致场景 |
| SOA/ESB | 服务契约、企业服务总线、编排 | 服务契约与总线 | 异构系统集成 | 追求极简、总线成为瓶颈 |
| 解释器/规则系统 | 虚拟机、解释执行、规则库 | 指令/规则 | 脚本、DSL、专家系统 | 追求最高运行效率 |
C2 风格要记三点：构件与连接件的层次化组织；构件只能通过顶部和底部两个端口交互；向上发请求，向下发通知，上层构件可以感知下层但下层不知道上层。这个顺序如果反过来就错，考过。
微服务考点我重点提醒：微服务不是分布式单体。如果你拆完之后所有服务共享一个库、必须一起发布，那就是分布式单体，比单体更糟。真正的微服务强调每个服务拥有自己的数据、独立部署，并伴随服务发现、API 网关、熔断限流、链路追踪、配置中心等一整套治理。
2.5 高频考点与易错点
| 考点 | 高频问法 | 易错点 |
|---|---|---|
| 风格判断 | 给场景选风格 | 把事件驱动和发布订阅当成两回事；实际上发布订阅是事件系统的典型形式 |
| 管道-过滤器 | 过滤器之间能否共享状态 | 标准定义里过滤器不共享状态、彼此不知对方存在 |
| 黑板 | 三个组成部分 | 把"控制"写成"用户接口" |
| C/S 与 B/S | 三层比两层好在哪 | 忘了"可伸缩、安全、易复用"这三点 |
| C2 | 请求/通知的方向 | 写反方向 |
一句话备忘：数据流看"流"，调用返回看"层"，独立构件看"事件"，虚拟机看"解释"，仓库看"共享数据"。口诀：流层事解仓。
3. 质量属性与架构评估
3.1 质量属性分类
教材把质量属性按"什么时候能观察到"分成两类：运行期可以观察到的（性能、安全性、可用性、功能性、易用性），和开发期才能观察到的（可修改性、可变性、可扩展性、互操作性、可集成性、可移植性、可测试性等）。这两类里，考试最爱问的是性能、可用性、安全性、可修改性、可测试性、易用性这六个的战术。
3.2 质量属性场景的六要素
质量属性场景是把模糊的"要快""要稳"变成可度量描述的模板，一共六要素：
- 刺激源：谁产生了刺激（用户、其他系统、定时器、攻击者……）；
- 刺激：到达系统的事件（一个请求、一次故障、一个变更需求）；
- 环境：刺激到来时系统处于什么状态（正常、过载、降级、开发期）；
- 制品：被刺激的对象（整个系统、某个模块、数据库）；
- 响应：系统做了什么；
- 响应度量：怎么衡量响应是否达标（时延、吞吐、恢复时间、修改工作量）。
举个例子：用户（刺激源）在正常负载下（环境）提交下单请求（刺激），订单服务（制品）处理并返回结果（响应），95% 的请求在 500ms 内完成（响应度量）。题目常给你一段话让你填空，或者问"以下哪一项不是六要素"。记口诀：源、激、环、制、响、度。
3.3 战术速查
战术就是"为了达成某种质量属性而采取的设计决策"。下表按属性列出教材里的主要战术：
| 质量属性 | 战术分类 | 具体战术 |
|---|---|---|
| 性能 | 资源需求 | 提高计算效率、减少计算开销、管理事件率、控制采样频率、限制执行时间、限制队列大小 |
| 资源管理 | 引入并发、维持数据或计算的多个副本、增加可用资源 | |
| 资源仲裁 | 先进先出、固定优先级、动态优先级、静态调度 | |
| 可用性 | 错误检测 | 命令/响应（ping/echo）、心跳、异常 |
| 错误恢复 | 表决、主动冗余（热重启）、被动冗余（暖重启）、备件、影子操作、状态再同步、检查点/回滚 | |
| 错误预防 | 服务器下线、事务、进程监视器 | |
| 安全性 | 抵抗攻击 | 身份认证、授权、数据加密、限制暴露、限制访问、维护数据机密性与完整性 |
| 检测攻击 | 入侵检测系统 | |
| 从攻击中恢复 | 恢复（复用可用性战术）、审计追踪、不可否认 | |
| 可修改性 | 局部化修改 | 维持语义一致性、预期期望的变更、泛化模块、限制可选择项 |
| 防止连锁反应 | 信息隐藏、维持现有接口、限制通信路径、仲裁者的使用 | |
| 推迟绑定时间 | 运行时注册、配置文件、多态、组件替换、遵守已定义的协议 | |
| 可测试性 | 输入/输出 | 记录/回放、分离接口与实现、专用测试接口 |
| 内部监控 | 内置监视器 | |
| 易用性 | 运行时 | 撤销、取消、聚合命令、显示系统状态 |
| 设计时 | 把用户界面与系统其他部分分离（如 MVC） |
补充一个我觉得最容易混的点：可用性和可靠性不同。可靠性看"在规定条件和时间内无故障运行的概率"，可用性看"任意时刻系统能正常工作的概率"，公式是 MTTF / (MTTF + MTTR)，一个偏"不出事"，一个偏"出事了能多快好"。表决、冗余这些都是为了提升可用性。
3.4 敏感点、权衡点、风险点、非风险点
- 敏感点：为了实现某个质量属性，一个或多个构件所具有的特性。比如"数据库的副本数量"对可用性敏感。
- 权衡点：影响多个质量属性的特性，是多个敏感点的交集。比如加密强度既影响安全性，又影响性能。
- 风险点：不好的架构决策，可能带来隐患。
- 非风险点：好的架构决策，通常是隐含的。
判断技巧：题干里出现"提高 A 会降低 B"的，选权衡点；单方面依赖某参数的，选敏感点。
3.5 ATAM 是什么
ATAM（Architecture Tradeoff Analysis Method，架构权衡分析方法）由 SEI 提出，是基于场景的评估方法：它不仅评估架构是否满足质量属性目标，还分析质量属性之间的权衡。它分四个阶段共九个步骤，我用图画一下：
这里的阶段命名不同资料略有差异（有的把前两步合成"展示"，把 4–6 叫"调查与分析"），但九个步骤的顺序是一致的：介绍 ATAM、介绍商业动机、介绍架构、识别架构方法、生成质量属性效用树、分析架构方法、头脑风暴并对场景排序、再次分析架构方法、表述结果。考试常让你把某一步放到对的位置，或者问"效用树是第几步"（第 5 步）。
3.6 评估方法家族
| 类型 | 代表 | 特点 |
|---|---|---|
| 基于调查问卷或检查表 | 问卷/检查表 | 灵活、通用，依赖评审者经验，主观性较强 |
| 基于场景 | SAAM、ATAM、SAEM | SAAM 侧重可修改性与功能，ATAM 关注多质量属性与权衡；场景是核心 |
| 基于度量 | 耦合度、内聚度、复杂度等指标 | 客观定量，但指标与质量属性的对应需验证 |
3.7 高频考点与易错点
| 考点 | 常见问法 | 易错点 |
|---|---|---|
| 六要素 | 给一句话，问某成分是哪个要素 | 把"响应"与"响应度量"混淆；度量必须是可测的 |
| 战术归类 | 心跳、ping/echo 属于哪类 | 属于错误检测，不是恢复 |
| 安全性战术 | 入侵检测归哪类 | 属于"检测攻击"，不是"抵抗攻击" |
| 可修改性 | "信息隐藏"属于哪类 | 属于防止连锁反应 |
| ATAM | 效用树在第几步；权衡点定义 | 把 ATAM 当成"基于度量"的方法 |
一句话备忘：性能三件套：需求、管理、仲裁；可用性三件套：检测、恢复、预防；安全性三件套：抵抗、检测、恢复；可修改性三件套：局部化、防连锁、推迟绑定。ATAM 记"效用树第五，结果第九"。
4. 软件架构的描述：4+1 视图、ADL 与 DSSA
4.1 Kruchten 4+1 视图
Philippe Kruchten 在 1995 年提出 4+1 视图模型，用五个视图从不同角度描述架构，其中"+1"是场景，用来把四个视图串起来。
| 视图 | 关注的人 | 关注的内容 | 常用图 |
|---|---|---|---|
| 逻辑视图 | 最终用户 | 系统提供的功能，对象与类的抽象 | 类图、状态图 |
| 进程视图 | 系统集成人员 | 并发、同步、性能、可伸缩性 | 活动图、顺序图 |
| 开发视图（实现视图） | 程序员、软件管理人员 | 模块、包、层次，软件在开发环境中的组织 | 组件图、包图 |
| 物理视图（部署视图） | 系统工程师 | 软件到硬件的映射，拓扑、通信 | 部署图 |
| 场景（用例视图） | 所有涉众 | 用例，验证与说明前四个视图 | 用例图 |
记忆口诀：逻辑看用户，进程看集成，开发看程序员，物理看工程师，场景串起来。真题里的经典问法是"XX 视图面向的对象是谁"，还有"进程视图关注什么"（并发、同步）。
4.2 架构描述语言与相关标准
- ADL：用形式化方式描述架构的语言，包括构件、连接件、配置。常见有 Wright、Darwin、Rapide、ACME、C2 SADL、UniCon 等。考试通常问"ADL 的三个基本要素是什么"——构件、连接件、架构配置。
- ISO/IEC/IEEE 42010（前身 IEEE 1471）：规定架构描述的组成——涉众、关注点、视点、视图、模型、原理。视点是"如何构造视图的规约"，视图是"从某视点看到的系统"。
- UML：可以作为半形式化的架构描述手段，但缺少对连接件的一等支持。
4.3 DSSA 与软件产品线
DSSA（领域特定软件架构）是"在一个特定领域中，为一组应用提供组织结构参考的标准软件体系结构"。基本活动分三个阶段：领域分析、领域设计、领域实现；参与人员有领域专家、领域分析人员、领域设计人员、领域实现人员。软件产品线则是在共性管理、变化管理的基础上，基于核心资产系统化复用来生产一组相似产品，常见组织方式有：核心资产开发 + 产品开发两个基本活动，再加上技术与组织管理。
容易被忽略的对比：DSSA 强调"领域的参考架构与复用"，产品线强调"一组产品的规模化生产"，而架构复用是它们的共同基础。
4.4 高频考点与易错点
| 考点 | 易错点 |
|---|---|
| 4+1 视图 | 把开发视图与物理视图对象弄反；把"+1"说成第五个技术视图，其实是场景 |
| ADL | ADL 三要素写成"构件、接口、约束" |
| DSSA | 三阶段写成"分析、设计、测试"，应为分析、设计、实现 |
一句话备忘：4+1 视图五看：逻辑（用户）、进程（集成）、开发（程序员）、物理（工程师）、场景（串联）。
5. 软件工程
5.1 开发模型对比
| 模型 | 关键词 | 适用 | 缺点 |
|---|---|---|---|
| 瀑布 | 阶段严格顺序、文档驱动、每阶段评审 | 需求明确稳定 | 反馈晚、需求变化代价大 |
| V 模型 | 开发阶段与测试阶段一一对应（需求—验收、概要设计—集成、详细设计—单元） | 强调测试尽早介入 | 仍是线性、变更困难 |
| 原型 | 快速原型、抛弃型与演化型 | 需求不明确 | 易被误当成最终产品 |
| 增量 | 分批交付功能，先核心后扩展 | 需求相对清楚、要早期交付 | 架构需一开始就稳 |
| 螺旋 | 风险驱动，每圈：目标、风险分析、开发验证、评审计划 | 大型高风险项目 | 依赖风险评估能力，成本高 |
| 喷泉 | 面向对象、迭代、无缝、阶段可重叠 | OO 开发 | 管理难度大 |
| RAD | 组件复用、并行开发、短周期（60–90 天） | 模块化好的信息系统 | 要求团队与组件成熟 |
| RUP | 用例驱动、以架构为中心、迭代增量；四阶段：初始、精化、构造、移交 | 大型 OO 项目 | 裁剪不当会重 |
判断技巧：看到"风险"选螺旋；看到"需求不明确、快速让用户看到"选原型；看到"测试贯穿、左右对应"选 V；看到"用例驱动、架构为中心、迭代"选 RUP。RUP 四阶段口诀：初精构移。
5.2 敏捷、XP、Scrum 与 DevOps
敏捷宣言的四个价值观：个体和互动高于流程和工具；可工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。注意是"高于"，不是"取代"，题目喜欢让你判断"敏捷是否不要文档"，答案当然是要，只是不以文档为核心。
- XP：价值观是沟通、简单、反馈、勇气（后来加上尊重）；实践包括结对编程、测试驱动开发、重构、持续集成、小型发布、现场客户、集体代码所有权、40 小时工作周等。
- Scrum：三个角色（产品负责人、Scrum Master、开发团队）；五个事件（Sprint、Sprint 计划会、每日站会、Sprint 评审会、Sprint 回顾会）；三个工件（产品待办列表、Sprint 待办列表、增量）。Sprint 一般不超过一个月。
- 其他敏捷方法：水晶方法（Crystal）、特征驱动开发（FDD）、自适应软件开发（ASD）、DSDM 等。
- DevOps：打通开发与运维，强调持续集成、持续交付/部署、基础设施即代码、监控与反馈。它不是某个工具，而是文化加实践加工具链。
5.3 需求工程
需求分三个层次：业务需求（组织为什么要做）、用户需求（用户要完成什么任务）、系统需求（系统必须做什么，包括功能需求、非功能需求、设计约束）。需求工程的主要活动：需求获取、需求分析、需求规格说明、需求验证、需求管理。
| 活动 | 常用方法与工具 | 要点 |
|---|---|---|
| 获取 | 访谈、问卷、观察、原型、联合应用开发（JAD）、用例、情景分析 | 多渠道交叉验证，防止遗漏隐含需求 |
| 分析 | 数据流图、实体联系图、状态转换图、用例 | 冲突识别与协商，需求优先级 |
| 规格说明 | SRS 文档、模型 | 无二义、完整、一致、可验证、可追踪 |
| 验证 | 评审、原型验证、测试用例推导 | 需求评审是成本最低的缺陷预防手段 |
| 管理 | 变更控制、基线、需求跟踪矩阵 | 变更走 CCB（变更控制委员会） |
提醒：需求跟踪分正向跟踪（需求到设计、代码、测试）与逆向跟踪（反过来），用来防止"多做"和"漏做"。
5.4 软件测试
测试阶段
单元测试（针对模块，多用白盒）→ 集成测试（接口，方式包括大爆炸、自顶向下、自底向上、三明治）→ 系统测试（功能、性能、压力、安全、兼容、容量、恢复）→ 验收测试（用户参与，α 测试在开发方环境由用户在开发者指导下进行，β 测试在用户环境无开发者在场）。回归测试贯穿修改后各阶段，冒烟测试则是对构建版本的初步验证。
黑盒与白盒
| 类型 | 方法 | 说明 |
|---|---|---|
| 黑盒 | 等价类划分、边界值分析、判定表、因果图、错误推测、场景法、正交试验 | 只看输入输出，不看内部 |
| 白盒 | 语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖、基本路径测试 | 基于内部逻辑结构 |
覆盖强弱排序（由弱到强）：语句 < 判定 < 条件 < 判定/条件 < 条件组合 < 路径。条件组合覆盖能保证判定/条件覆盖，是很强的一种；路径覆盖最强但不一定可行。圈复杂度公式 V(G) = E − N + 2（边数减节点数加 2），也等于判定节点数加 1，等于独立路径条数，用于基本路径测试。
5.5 软件维护、演化与重构
维护类型有四种：改正性（修错）、适应性（适应环境变化）、完善性（增加功能、提高性能，比例通常最高）、预防性（为了未来更好维护而重构）。可维护性的评价维度：可理解性、可测试性、可修改性。相关技术：逆向工程（从代码恢复设计/需求）、重构（不改变外部行为地改善内部结构）、再工程（逆向 + 重构 + 正向）。老系统改造是近年案例题的热门方向，综合知识里则考"哪种维护"。
5.6 软件质量、可靠性与成熟度
- 质量模型：ISO/IEC 25010 的产品质量模型（2011 版）有八个特性：功能适合性、性能效率、兼容性、易用性、可靠性、信息安全性、可维护性、可移植性。我隐约记得 2023 年有修订版本调整了特性名称与数量，但没有查到原文，考试仍以教材版本为准。
- 可靠性指标：MTTF（平均无故障时间）、MTTR（平均修复时间）、MTBF = MTTF + MTTR，可用性 = MTTF / (MTTF + MTTR)。串联与并联系统的可靠度计算放在下篇"数学与运筹"里细讲。
- CMMI：五级——初始级、已管理级、已定义级、量化管理级、优化级。口诀：初管定量优。
- 配置管理：配置项、基线、版本控制、变更控制；软件评审：走查、审查、技术评审，正式程度依次上升。
5.7 高频考点与易错点
| 考点 | 易错点 |
|---|---|
| 开发模型 | 把螺旋当成"多次瀑布"；螺旋的灵魂是风险分析 |
| 敏捷 | Scrum 角色写成"项目经理"；Scrum 没有项目经理这个角色 |
| 测试覆盖 | 混淆判定覆盖与条件覆盖强度；条件覆盖不一定满足判定覆盖 |
| 集成测试 | 三明治是自顶向下与自底向上的结合 |
| 维护 | 把"因用户需求增加功能"归成适应性；应是完善性 |
| 成熟度 | CMMI 二级叫"已管理级"，别写成"可重复级"（那是 CMM） |
一句话备忘：模型看关键词，敏捷看价值观，测试记覆盖强弱，维护记"改适完预"，成熟度记"初管定量优"。
6. 设计模式
设计模式来自 GoF 的《设计模式》一书，共 23 种，分创建型（5）、结构型（7）、行为型（11）。考试要求：知道每种模式的意图，能根据场景选模式，能区分容易混淆的模式。
6.1 创建型（5 种）
| 模式 | 一句话意图 | 识别场景 |
|---|---|---|
| 工厂方法（Factory Method） | 定义创建对象的接口，让子类决定实例化哪个类 | 创建逻辑延迟到子类 |
| 抽象工厂（Abstract Factory） | 创建一系列相关或相互依赖的对象，不指定具体类 | 产品族、换整套主题/数据库 |
| 生成器（Builder） | 将复杂对象的构建与表示分离，同样的过程可创建不同表示 | 分步骤构建复杂对象 |
| 原型（Prototype） | 通过复制现有实例来创建新对象 | 创建成本高，需要克隆 |
| 单例（Singleton） | 保证一个类只有一个实例并提供全局访问点 | 配置、线程池、日志器 |
口诀：抽象工厂原型建，单例创建五个全（抽象工厂、工厂方法、原型、生成器、单例）。
6.2 结构型（7 种）
| 模式 | 一句话意图 | 识别场景 |
|---|---|---|
| 适配器（Adapter） | 把一个类的接口转换成客户期望的另一个接口 | 接口不兼容的老代码整合 |
| 桥接（Bridge） | 将抽象部分与实现部分分离，使两者独立变化 | 两个维度独立扩展 |
| 组合（Composite） | 将对象组合成树形结构，使单个与组合对象一致对待 | 文件夹/文件、菜单树 |
| 装饰器（Decorator） | 动态地给对象添加额外职责 | IO 流、功能叠加 |
| 外观（Facade） | 为子系统提供一致的高层接口 | 简化复杂子系统的调用 |
| 享元（Flyweight） | 运用共享技术有效支持大量细粒度对象 | 大量相似对象，节省内存 |
| 代理（Proxy） | 为其他对象提供代理以控制对它的访问 | 远程/虚拟/保护/缓存代理 |
口诀：适桥组装外享代。
三对最容易混：适配器 vs 桥接（适配器事后补救，桥接事前设计）；装饰器 vs 代理（装饰器增强功能，代理控制访问）；外观 vs 适配器（外观简化接口，适配器转换接口）。
6.3 行为型（11 种）
| 模式 | 一句话意图 | 识别场景 |
|---|---|---|
| 责任链（Chain of Responsibility） | 让多个对象都有机会处理请求，沿链传递 | 审批流、过滤链 |
| 命令（Command） | 将请求封装为对象，支持排队、撤销 | 撤销/重做、任务队列 |
| 解释器（Interpreter） | 给定语言，定义其文法的表示与解释器 | 简单 DSL、表达式 |
| 迭代器（Iterator） | 顺序访问聚合对象元素而不暴露内部 | 遍历集合 |
| 中介者（Mediator） | 用中介对象封装一组对象的交互，减少相互引用 | 聊天室、对话框控件联动 |
| 备忘录（Memento） | 不破坏封装的前提下捕获并外部保存对象状态 | 快照、撤销 |
| 观察者（Observer） | 对象间一对多依赖，一个变化通知所有依赖者 | 事件、订阅 |
| 状态（State） | 对象内部状态改变时改变其行为 | 状态机、订单状态 |
| 策略（Strategy） | 定义一族算法，封装并可互换 | 促销规则、排序算法切换 |
| 模板方法（Template Method） | 定义算法骨架，把某些步骤延迟到子类 | 框架钩子、固定流程 |
| 访问者（Visitor） | 在不改变元素类的前提下定义作用于元素的新操作 | 结构稳定、操作多变 |
口诀：责命解迭中，备观状策模访（责任链、命令、解释器、迭代器、中介者、备忘录、观察者、状态、策略、模板方法、访问者，一共 11 个）。
再补两个易混：状态 vs 策略（状态由内部转换触发，策略由客户端选择）；观察者 vs 中介者（观察者是一对多的广播，中介者是多对多的协调）。
6.4 设计原则
- 单一职责（SRP）：一个类只有一个引起它变化的原因；
- 开闭原则（OCP）：对扩展开放，对修改关闭；
- 里氏替换（LSP）：子类可以替换父类而不改变程序正确性；
- 依赖倒置（DIP）：依赖抽象而不是具体；
- 接口隔离（ISP）：客户端不应依赖它不需要的接口；
- 迪米特法则（最少知识）：只与直接朋友通信；
- 合成复用：优先组合而不是继承。
6.5 高频考点与易错点
| 考点 | 易错点 |
|---|---|
| 模式分类 | 把适配器写成创建型；把访问者写成结构型 |
| 场景选型 | "多个对象依赖一个对象变化" 选观察者，不是中介者 |
| 抽象工厂 vs 工厂方法 | 产品族用抽象工厂；单一产品用工厂方法 |
| 单例 | 多线程下需要考虑线程安全（双重检查、静态内部类、枚举） |
一句话备忘：创建型 5、结构型 7、行为型 11，总数 23；创建看"怎么造"，结构看"怎么拼"，行为看"怎么协作"。
7. 系统设计：模块化、耦合内聚与 UML
7.1 耦合与内聚
好设计的标准是"高内聚、低耦合"。两个都有等级，顺序背熟就是白拿分：
| 类别 | 由低（好）到高（差）或反之 | 口诀 |
|---|---|---|
| 耦合（越低越好） | 非直接耦合 < 数据耦合 < 标记耦合 < 控制耦合 < 外部耦合 < 公共耦合 < 内容耦合 | 无数标控外公内 |
| 内聚（越高越好） | 偶然 < 逻辑 < 时间 < 过程 < 通信 < 顺序 < 功能 | 偶逻时过通顺功 |
解释几个易混的：数据耦合只传简单数据；标记耦合传数据结构；控制耦合传控制信号；公共耦合共享全局数据区；内容耦合直接访问对方内部，最坏。内聚里，时间内聚是"同一时间执行的操作放一起"（如初始化），过程内聚是"按特定顺序执行"，通信内聚是"操作同一数据"，顺序内聚是"前一个输出是后一个输入"。
7.2 结构化设计
结构化设计的产物是系统结构图（模块层次），衡量指标有：深度、宽度、扇入（被调用的上级模块数，越大越好，说明复用）、扇出（调用的下级模块数，一般 3–4 较好，最好不超过 7）。设计方法有面向数据流（变换分析、事务分析）等。
7.3 UML 2.x 十四种图
| 类别 | 图 | 用途 |
|---|---|---|
| 结构图（7） | 类图 | 类与关系，最核心 |
| 对象图 | 某时刻实例快照 | |
| 组件图 | 组件及其接口依赖 | |
| 部署图 | 节点与制品的物理部署 | |
| 包图 | 包与依赖，组织模型 | |
| 组合结构图 | 类的内部结构与协作 | |
| 轮廓图（Profile） | 扩展 UML 的构造型 | |
| 行为图（7） | 用例图 | 用户视角的功能 |
| 活动图 | 流程与并发，类似流程图 | |
| 状态机图 | 对象状态迁移 | |
| 顺序图 | 对象间消息按时间排序 | |
| 通信图 | 对象间消息与连接关系（强调结构） | |
| 交互概览图 | 活动图与顺序图的结合 | |
| 时序图（Timing） | 状态随时间变化 |
类图的关系：依赖（虚线箭头，使用关系）、泛化（空心三角实线，继承）、实现（空心三角虚线）、关联（实线）、聚合（空心菱形，整体与部分可分离）、组合（实心菱形，整体与部分同生共死）。顺序图与通信图语义等价（强调点不同），常考"强调时间顺序选顺序图，强调结构选通信图"。
7.4 高频考点与易错点
| 考点 | 易错点 |
|---|---|
| 耦合内聚排序 | 把外部耦合与公共耦合的顺序搞反 |
| 聚合与组合 | 菱形空实颠倒 |
| UML 图归类 | 把用例图放进结构图；把部署图放进行为图 |
| 顺序图与通信图 | 强调重点混淆 |
一句话备忘：耦合"无数标控外公内"，内聚"偶逻时过通顺功"，UML 结构七行为七。
8. 一页速查：本篇必背清单
| 主题 | 必背项 |
|---|---|
| 架构风格 | 五大类：数据流、调用返回、独立构件、虚拟机、仓库；C2 请求向上、通知向下 |
| 质量属性场景 | 六要素：刺激源、刺激、环境、制品、响应、响应度量 |
| ATAM | 9 步，效用树第 5 步；敏感点、权衡点、风险点、非风险点 |
| 4+1 视图 | 逻辑、进程、开发、物理 + 场景 |
| 开发模型 | 瀑布、V、原型、增量、螺旋、喷泉、RAD、RUP |
| 测试 | 覆盖强弱；V(G)=E−N+2；集成测试四种方式 |
| 设计模式 | 5 + 7 + 11 = 23 |
| 系统设计 | 耦合 7 级、内聚 7 级、UML 14 图 |
学到这里，你已经吃下综合知识里分值最大的两块。建议复习节奏：先通读一遍教材相关章节，然后马上拿近几年真题按知识点分类刷，把错题对应到本文的表格里补记，第二遍只看易错点和口诀。下篇讲数据库、网络安全、嵌入式与新技术，以及考试里常出现的计算题。
9. 典型题型演练：把知识点变成"选项排除术"
下面几道是我按考试常见考法自拟的示例题（不是真题原文，也不声称考过），目的是演示怎么把上面的表格用起来。综合知识 75 题，150 分钟，平均一题不到两分钟，所以"看到关键词直接对应知识点"的能力比"慢慢推导"更重要。
9.1 架构风格题
题：某系统由若干独立的处理步骤组成，每个步骤从输入读数据、做转换、把结果写到输出，步骤之间只通过数据传递，彼此不知道对方的存在，且希望能灵活重组步骤顺序。适合采用哪种风格？
拆解：关键词是"步骤只通过数据传递""彼此不知道对方""灵活重组"，对应数据流风格里的管道-过滤器。如果选项里同时有"批处理序列"，要看题干有没有提"整批处理完再交给下一步"；没有的话选管道-过滤器。如果选项有"事件驱动"，注意事件驱动是靠事件触发而不是数据流动，排除。
拓展：如果题干改成"多个专家程序共同修改一份共享数据直到得出结论"，就是黑板；改成"上层构件发请求，下层构件发通知，构件通过端口通信"，就是 C2；改成"服务各自拥有数据、独立部署、通过轻量协议协作"，就是微服务。
9.2 质量属性场景题
题："在线支付系统在大促期间（环境），用户提交订单（刺激），订单服务（制品）应在 2 秒内响应（响应度量）。"请指出其中的刺激源与响应。
拆解：刺激源是"用户"，刺激是"提交订单"，环境是"大促期间"，制品是"订单服务"，响应是"处理订单并返回结果"，响应度量是"2 秒内"。这道题的陷阱在于：原文没有明说的"响应"要你补上，"响应度量"必须是可测的数值。如果题目问"这属于哪类质量属性"，答性能。再问"可以采取哪些战术"，从表里挑：引入并发、增加资源、维持多个副本、限制队列长度、管理事件率。
9.3 战术归类题
题：下列哪项属于可用性战术中的"错误检测"？
A. 主动冗余 B. 心跳 C. 影子操作 D. 检查点/回滚
拆解：心跳（以及 ping/echo、异常）是错误检测；A、C、D 都是错误恢复。答案 B。这类题的通用技巧：先记分类名，再记成员，分类名 3 个就够了（检测、恢复、预防）。再顺手记一个反例：事务、进程监视器是错误预防。
9.4 ATAM 与风险点题
题：评审发现"数据库主库是唯一写入点，一旦宕机，订单无法提交"。这在 ATAM 里最可能被归为哪一种？
拆解：这是一个对可用性不利的架构决策，属于风险点。若评审者进一步指出"增加从库数量可以改善读性能，但会拉长主从同步延迟并影响一致性"，则"副本数量"是权衡点（同时影响性能、一致性和可用性）。如果说"副本数量决定了可用性水平"，则是敏感点。三个词的区分，我的记忆办法是：敏感——"对一个属性敏感"；权衡——"两头拉扯"；风险——"这里可能出事"。
9.5 开发模型选择题
| 题干特征 | 选 | 排除理由 |
|---|---|---|
| 需求不清，需要快速给用户看界面和交互 | 原型 | 瀑布要求需求确定 |
| 大型军工/金融，风险高，每阶段评估风险 | 螺旋 | 增量不强调风险 |
| 需求稳定，文档严谨，阶段评审 | 瀑布 | 敏捷不以文档为中心 |
| 分批交付，先上线核心功能 | 增量 | 原型是抛弃或演化，不强调批次交付 |
| 迭代周期短，客户全程参与，每日站会 | 敏捷（Scrum/XP） | RUP 更重 |
9.6 测试用例设计题
题：输入为年龄，合法范围 18–60 岁（含）。用边界值分析法，至少应选取哪些测试值？
拆解：典型的边界值取法是上点、下点及其内外相邻点：17、18、19、59、60、61。如果是"三值法"，则取 17、18、60、61 及一个中间值。考试里若给出的选项是 6 个值的组合，直接选包含这六个的那一项。等价类方面，有效等价类是 18–60，无效等价类是小于 18 与大于 60，另加"非数字"这类类型错误。
圈复杂度小题：一段流程图有 11 条边、9 个节点，则 V(G) = 11 − 9 + 2 = 4，需要 4 条独立路径。如果告诉你有 3 个判定节点，则 V(G) = 3 + 1 = 4，两种算法应该一致，你可以用来互相验算。
9.7 设计模式选择题
| 场景 | 模式 | 排除项与理由 |
|---|---|---|
| 文字编辑器需要撤销与重做 | 命令 或 备忘录 | 命令封装操作，备忘录保存状态；按选项二选一，若强调"保存对象内部状态快照"选备忘录 |
| 订单状态变化触发不同行为 | 状态 | 策略是客户端选择算法，状态由对象内部转换触发 |
| 给咖啡加牛奶、糖、奶泡，可任意叠加 | 装饰器 | 继承会导致类爆炸 |
| 一个类只允许存在一个实例 | 单例 | 享元是共享多个细粒度对象 |
| 屏蔽复杂子系统的调用细节，提供统一入口 | 外观 | 适配器是接口转换 |
| 树形结构，叶子与容器被同等对待 | 组合 | 装饰器是叠加职责 |
| 请求依次经过多个处理者，谁能处理谁处理 | 责任链 | 命令是把请求变成对象 |
9.8 耦合内聚判断
题：模块 A 直接修改模块 B 内部的局部变量，属于哪种耦合？多个模块通过全局变量交换数据，又属于哪种？
拆解：前者内容耦合（最差），后者公共耦合。一个小窍门：涉及"跳转进对方内部""改对方代码或数据"就是内容耦合；涉及"共享全局区"就是公共耦合；涉及"传一个开关让对方走不同分支"就是控制耦合。
10. 我给自己排的复习顺序（不是亲历经验，是整理后的建议）
- 第一遍（约两周）：只读教材对应章节，配合本文的表格建立框架，不追细节。此时画一张自己的思维导图，比抄十页笔记有用。
- 第二遍（约两周）：按知识点分类刷近几年综合知识真题，错题按"风格/质量属性/工程/模式/系统设计"归类，记进错题本，并在错题旁写上"我当时为什么选错"。
- 第三遍（考前两周）：只翻速查表、口诀和错题本；整套模拟按 150 分钟计时，训练"关键词—知识点"的反射速度。
- 与案例、论文联动：架构风格、质量属性、ATAM、设计模式这几块也是案例分析的主战场，所以背的时候要顺便想"我在项目里怎么用"，一份学习产出多科受益。
再强调一次可信度问题：上述节奏是我根据公开备考文章的共性整理的，各家写的备考周期从两个月到半年不等，并没有统一标准；你的基础、工作强度、目标批次都会影响，请自行调整。
参考资料
- 希赛网：软考高级系统架构设计师《综合知识》分值分布表——综合知识各知识板块题数区间的整理，本文考情部分参考。
- 希赛网：系统架构设计师考试题型及分值分布——三科题型、时长、45 分合格线的说明。
- 广州市人社局：2026 年度计算机技术与软件专业技术资格（水平）考试报考热点问答——2026 年上下半年考试日期与高级科目安排。
- GitHub：xxlllq/system_architect——个人整理的备考资料仓库，说明教材为《系统架构设计师教程（第 2 版）》及考试大纲（第 2 版）。
- 个人博客：2026 年软考系统架构设计师备考注意事项——公开考生整理的考点分布与备考节奏；其中下半年日期与官方口径不一致，本文未采用。
一起聊聊