系统架构设计师 · 考前速查手册

📐ATAM 架构评估核心概念

六个关键概念（必背）

概念	标准定义	判断关键词
敏感点	一个架构决策影响一个质量属性	只涉及1个质量属性，影响显著
权衡点	一个架构决策影响多个质量属性（此升彼降）	涉及≥2个质量属性
风险	架构决策存在潜在负面结果	"团队能力不足""经验欠缺""可能成为瓶颈"
非风险	经过分析，架构决策没有问题	"有效满足需求""没有负面影响"

敏感点 vs 风险陷阱："主库写入可能成为瓶颈"看似风险，但它分析的是对性能这一个属性的影响 → 是敏感点。"团队能力不足"这种组织层面不确定因素才是风险。

ATAM评估九步法

介绍ATAM方法
介绍业务驱动因素
介绍架构方案
识别架构方法
生成质量属性效用树重点
分析架构方法
头脑风暴场景并排序
再次分析架构方法
报告结果

效用树四级结构

根节点 → 质量属性 → 质量属性细化 → 场景

每个场景带优先级（高/中/低），高优先级场景用于驱动后续分析。

🏗️五大架构风格速查

1. 数据流风格

管道-过滤器

构件（过滤器）有输入端和输出端
通过管道传递数据流
不共享状态
✅ 支持并行、高内聚低耦合
❌ 不适合交互式应用

批处理

每步处理完整数据集
前一步完全结束后才开始下一步
适合：数据转换、报表生成

2. 调用/返回风格

子风格	特点	典型应用
主程序/子程序	自顶向下调用	传统过程式编程
面向对象	封装+继承+多态	Java/C#应用
层次结构	分层，每层只与相邻层交互	TCP/IP协议栈、OSI七层

3. 独立构件风格

进程通信

消息传递
同步/异步通信
解耦构件

事件驱动（隐式调用）

构件不直接调用
通过事件触发
✅ 复用性高、可扩展
❌ 放弃了对计算的控制
典型：GUI、MVC中的观察者

4. 虚拟机风格（重点！）

解释器

核心组件：
• 解释引擎
• 被解释的程序
• 程序状态
✅ 灵活性高
❌ 性能低
典型：JVM、Python解释器

基于规则的系统

规则库 + 推理引擎
适合：专家系统
事实 + 规则 → 结论

5. 仓库风格（重点！）

黑板系统

三大核心构件：
• 黑板（共享数据结构）
• 知识源（独立处理模块）
• 控制器（调度策略）
适合：语音识别、图像处理、AI推理
没有确定性解法的复杂问题

数据库系统

中央数据存储
客户端查询/更新
传统C/S架构

秒杀口诀：数调独虚仓 — 数据流、调用返回、独立构件、虚拟机、仓库。解释器和黑板是案例填空高频考点，组件名称必须精确记忆。

⭐质量属性辨析

六大质量属性关键词

属性	关键词	常见策略
性能	响应时间、吞吐量、延迟、并发	增加计算资源、减少计算开销、并发/并行、缓存
可用性	持续运行、停机时间、故障恢复、MTBF	冗余、心跳检测、故障转移、主从切换
可修改性	新增模块、插件扩展、接口变更	信息隐藏、接口抽象、松耦合、AOP
可维护性	修bug、定位问题、日常运维便利	模块化、日志、监控、文档
可伸缩性	增加机器、增加用户、水平/垂直扩展	负载均衡、分片、弹性伸缩
互操作性	与外部系统交互、数据交换、API集成	标准协议、中间件、适配器

三组易混辨析

性能 vs 可用性

带具体时间指标 → 性能
持续运行不中断 → 可用性

可修改 vs 可维护

加功能/加代码 → 可修改性
修bug/找问题 → 可维护性

可修改 vs 可伸缩

加功能模块 → 可修改性
加机器/加用户 → 可伸缩性

可修改 vs 互操作

改自己的代码 → 可修改性
跟外部系统打交道 → 互操作性

📊UML 图分类

13种图速记

行为图口诀："用活状序"

结构图（静态6种）	行为图（动态7种）
类图最常用	用例图最常用
对象图	活动图
包图	状态机图案例高频
组件图	序列图（顺序图）最常用
部署图	通信图（协作图）
组合结构图	定时图
	交互概览图

用例图是行为图，不是结构图！考试常考。

类间关系（耦合度从弱到强）

依赖 → 关联 → 聚合 → 组合 → 泛化(继承) → 实现

聚合：整体与部分可分离（雁群和大雁）
组合：整体与部分不可分离（鸟和翅膀）
泛化：继承关系（is-a）
实现：接口实现（implements）

状态图核心术语

状态（State）：对象在生命周期中的条件
转换（Transition）：从一个状态到另一个状态
事件（Event）：触发转换的条件
动作（Action）：转换时执行的操作
守卫条件（Guard）：[条件表达式]，满足才触发转换

🌐TCP/IP 协议族

OSI 七层模型（必背）

层号	名称	功能	核心协议/设备
7	应用层	为用户提供网络服务接口	HTTP、FTP、SMTP、DNS、DHCP、Telnet、SNMP、POP3、IMAP、SSH
6	表示层	数据格式转换、加密解密、压缩解压	JPEG、ASCII、SSL/TLS、MPEG
5	会话层	建立/管理/终止会话（通信同步）	NetBIOS、RPC、SQL会话
4	传输层	端到端可靠传输、流量控制	TCP、UDP、SPX
3	网络层	路由选择、寻址、拥塞控制	IP、ICMP、ARP、RARP、OSPF、BGP、IGMP
2	数据链路层	帧封装、差错检测、MAC寻址	Ethernet、PPP、HDLC、Frame Relay、VLAN、STP
1	物理层	比特流传输、电气/机械特性	RS-232、RJ-45、光纤、双绞线、中继器、集线器

七层从下到上：物数网传会表应（物理→数据链路→网络→传输→会话→表示→应用）

OSI vs TCP/IP 对照

OSI七层	TCP/IP四层	对应关系
应用层、表示层、会话层	应用层	OSI上三层合并为TCP/IP应用层
传输层	传输层	一一对应
网络层	网络层（网际层）	一一对应
数据链路层、物理层	网络接口层	OSI下两层合并为TCP/IP网络接口层

每层对应网络设备

层次	设备	作用
物理层	中继器、集线器（Hub）	信号放大/再生，不识别地址
数据链路层	网桥、交换机（Switch）	根据MAC地址转发帧
网络层	路由器（Router）	根据IP地址路由转发
传输层及以上	网关（Gateway）	协议转换，连接不同体系网络

交换机工作在数据链路层（看MAC地址），路由器工作在网络层（看IP地址）。集线器（Hub）工作在物理层，只是广播信号，不识别任何地址。

层次	功能	核心协议
应用层	为用户提供网络服务	HTTP、FTP、SMTP、DNS、DHCP、Telnet、SNMP、POP3、IMAP
传输层	端到端通信	TCP（可靠、面向连接）、UDP（不可靠、无连接）
网络层	路由和寻址	IP、ICMP、ARP、RARP、OSPF、BGP
网络接口层	物理链路传输	Ethernet、PPP、MAC

协议速记

可靠TCP三次握，无连接UDP快如飞

易混协议辨析

协议	端口	用途
HTTP	80	网页浏览
HTTPS	443	加密网页
FTP	20/21	文件传输
SMTP	25	发邮件
POP3	110	收邮件（下载后删除）
IMAP	143	收邮件（服务器同步）
DNS	53	域名解析
DHCP	67/68	自动分配IP
SNMP	161	网络管理
Telnet	23	远程登录（明文不安全）
SSH	22	加密远程登录

TCP vs UDP

TCP

面向连接（三次握手）
可靠传输、有序
流量控制、拥塞控制
适合：网页、邮件、文件传输

UDP

无连接
不可靠、无序
开销小、速度快
适合：视频流、DNS、直播

ARP 与 ICMP

ARP：IP地址 → MAC地址（地址解析协议）
RARP：MAC地址 → IP地址（反向）
ICMP：网络差错报告和控制（ping命令基于ICMP）

🔗区块链核心概念

四大核心概念

概念	说明
链式哈希结构	每个区块包含前一区块的哈希值，保证不可篡改
智能合约	链上自动执行的代码，满足条件自动触发（如以太坊Solidity）
共识机制	分布式节点达成一致的算法
去中心化	无中心化服务器，P2P网络，节点对等

六层模型（案例必背）

层级	名称	功能说明
1	数据层	底层数据结构，包括区块（区块头+区块体）、链式结构（前块哈希）、哈希函数（如SHA-256）、默克尔树（交易摘要）
2	网络层	P2P点对点网络，节点发现与通信，交易广播和区块传播机制，Gossip协议
3	共识层	让分布式节点对账本达成一致的算法：PoW（工作量证明）、PoS（权益证明）、DPoS（委托权益证明）、PBFT（实用拜占庭容错）
4	激励层	经济激励机制，发行代币/积分，奖励出块节点，鼓励诚实行为，惩罚恶意行为
5	合约层	智能合约的部署和执行环境，脚本代码、虚拟机（如EVM），实现业务逻辑自动化
6	应用层	面向用户的DApp（去中心化应用），如数字货币、供应链溯源、数字身份、NFT、DeFi

六层速记：数网共激合应（数据层→网络层→共识层→激励层→合约层→应用层）

智能合约详解（案例300字答题模板）

智能合约是部署在区块链上的可自动执行的程序代码，由以太坊首次提出并实现。它以"如果-那么"的逻辑形式定义交易规则，当预设条件被满足时，合约自动触发执行，无需第三方中介干预。

核心特征：
（1）自动执行：条件满足即触发，无需人工干预；
（2）不可篡改：部署后代码无法修改，运行结果确定；
（3）透明公开：代码在链上可验证、可审计；
（4）去信任：不依赖第三方，由代码逻辑保证执行。

开发语言：Solidity（以太坊）、Move（Diem）等。
运行环境：EVM（以太坊虚拟机）等链上虚拟机。
应用场景：数字资产交易、供应链自动结算、保险自动理赔、DeFi借贷协议。

区块链工作流程（案例必背）

用户发起交易：用户通过钱包客户端创建一笔交易，用私钥签名
交易广播：交易通过P2P网络广播到全网节点
节点验证：各节点收到交易后验证签名有效性、余额是否充足、格式是否合法
打包进区块：矿工/验证节点将验证通过的交易打包成候选区块
共识竞争：节点通过共识机制（如PoW算力竞争、PoS权益投票）竞争出块权
区块广播与验证：获胜节点将新区块广播到全网，其他节点验证区块合法性
追加到链上：验证通过后，新区块追加到区块链末尾，交易被确认
全网同步：所有节点更新本地账本副本，达成一致性状态

流程速记：发起 → 广播 → 验证 → 打包 → 共识 → 上链 → 同步

共识机制对比

PoW（工作量证明）

算力竞争出块
✅ 安全性高
❌ 耗能大、速度慢
代表：比特币

PoS（权益证明）

持币量决定出块权
✅ 节能、速度快
❌ 需质押、富者愈富
代表：以太坊2.0

安全风险

51%攻击：控制超过半数算力可篡改交易
智能合约漏洞：代码漏洞导致资金损失（如DAO事件）
私钥丢失：无法找回，资产永久丢失

案例答题关键词：不可篡改、可追溯、去中心化、共识机制、智能合约。遇到区块链题至少写出这五个。

📄LRU / FIFO / OPT 页面置换

LRU 手算方法

维护列表：左边=最近使用的，右边=最久没用的。命中→移到最左；缺页→淘汰最右，新页加最左。

三种算法对比

算法	淘汰策略	Belady异常
OPT	淘汰将来最久不用的（向后看）	不会
LRU	淘汰过去最近最久未用的（向前看）	不会
FIFO	淘汰最早进入的	可能

Belady异常 = 增加页框数反而缺页率上升。只有FIFO可能出现。LRU和OPT是栈式算法，不会。

缺页率公式

缺页率 = 缺页次数 / 总访问次数

快速判断技巧

前N次访问（N=页框数）必为缺页（初始为空）
刚被淘汰的页面如果马上又被访问，一定缺页
序列中有连续重复的页号 → 命中机会多

🔄PV 操作

基本规则

P(S)：S=S-1，若S<0则阻塞等待 | V(S)：S=S+1，若有等待进程则唤醒

P = 申请等待 | V = 释放通知

生产者-消费者

缓冲区容量N。empty=N, full=0, mutex=1：

生产者：P(empty) → P(mutex) → 写 → V(mutex) → V(full)
消费者：P(full) → P(mutex) → 读 → V(mutex) → V(empty)

P的顺序不能反（先P(empty)再P(mutex)，否则死锁）。V的顺序无所谓。N=1时可省略mutex。

多读者-写者

读者：P(mutex); rc++; if(rc==1)P(rw); V(mutex); 读; P(mutex); rc--; if(rc==0)V(rw); V(mutex)
写者：P(rw); 写; V(rw)

前趋同步

P1先完成：V(S) | P2后开始：P(S) | 信号量S=0

做题三问

谁等谁？ → 先完成的V，后开始的P
有没有互斥？ → 共享资源需要mutex
信号量初始值？ → 一般题目会给出

⚡流水线计算

三个核心公式

时钟周期：Δt = max(各段时间)

总时间：T = (级数k + 指令数n - 1) × Δt

吞吐率：TP = n / T | 加速比：S = 不用流水线时间 / T

计算示例

4级流水线，各段2ns/3ns/2ns/2ns，100条指令：

Δt = max(2,3,2,2) = 3ns
T = (4+100-1)×3 = 103×3 = 309ns
TP = 100/309 ns⁻¹
不用流水线：每条9ns×100=900ns，S=900/309≈2.91

气泡（Stall）

实际时间 = 理想时间 + m×(n-1)×Δt（m=每条指令插入的气泡数）

💾Cache 映射 + 死锁资源计算

Cache三种映射

方式	规则	优点	缺点
直接映射	块号%行数=固定行	速度快	冲突多
全相联	任意块放任意行	冲突最少	硬件复杂
N路组相联	先分组，组内N路任选	平衡	—

计算公式

总行数 = Cache容量/块大小 | 组数 = 总行数/N

RISC vs CISC

特征	RISC	CISC
指令数量	少	多
指令长度	固定	可变
寻址方式	简单（少）	丰富（多）
寄存器数量	多（>100）	少
控制器	硬布线	微程序
流水线	适合（大多1周期）	不适合
代表	ARM、MIPS	x86

死锁资源计算

m ≥ n×(X-1) + 1

m=资源总数，n=进程数，X=每个进程最多需要的资源数

含义：最坏情况每个进程各拿(X-1)个（差1个就能完成），再留至少1个给某个进程先完成释放。

寻址方式

方式	类比
立即寻址	直接给你钱
直接寻址	给你门牌号
寄存器寻址	钱在你口袋
寄存器间接寻址	口袋里有张纸条写着门牌号
基址寻址	门牌号+楼栋偏移
变址寻址	数组遍历（基址+下标）

🔢IP 子网划分

核心公式

子网数 = 2^n | 每子网主机数 = 2^m - 2

n=借的主机位数，m=剩余主机位数（减2=网络地址+广播地址）

常用掩码对照表

CIDR	子网掩码	借位	子网数	每子网主机
/25	255.255.255.128	1	2	126
/26	255.255.255.192	2	4	62
/27	255.255.255.224	3	8	30
/28	255.255.255.240	4	16	14
/29	255.255.255.248	5	32	6
/30	255.255.255.252	6	64	2

求网络地址

网络地址 = IP地址 AND 子网掩码

例：IP 192.168.10.130/26
130 = 10000010，/26掩码末字节=11000000(192)
AND = 10000000 = 128 → 网络地址 = 192.168.10.128

💰挣值分析

三个基本量

符号	名称	含义
PV	计划值	到某时点计划完成的工作预算
EV	挣值	到某时点实际完成的工作预算
AC	实际成本	到某时点实际花费

四个偏差指标

CV = EV - AC（成本偏差）>0=节约
SV = EV - PV（进度偏差）>0=超前
CPI = EV / AC（成本绩效指数）>1=节约
SPI = EV / PV（进度绩效指数）>1=超前

EV永远是分子！"偏差"用减法，"指数"用除法

预测公式

BAC = 完工总预算
EAC = BAC / CPI（典型偏差时）
ETC = EAC - AC（还需花多少）
VAC = BAC - EAC（完工偏差）

🗺️关键路径

关键路径 = 从起点到终点最长的路径 = 项目最短完成时间

总时差

总时差 = 最迟开始LS - 最早开始ES

总时差=0的活动 = 关键活动。关键活动连起来 = 关键路径。

做题方法

列举路径法（小项目）：画出所有路径，最长的是关键路径
ES/LS法（给了表格）：找总时差=0的活动，连成路径

易错点

关键路径不一定只有一条
关键活动delay一天 = 项目晚一天
非关键活动的总时差 = 可以拖延而不影响总工期的天数

🛡️等级保护 2.0

五个级别

级别	名称	备案	测评	适用
一级	自主保护级	不需	不需	小型系统
二级	指导保护级	需备案	不需强制测评	一般系统
三级	监督保护级	需备案	每年至少1次	重要系统（银行、电商）
四级	强制保护级	需备案	每半年至少1次	极重要（国防）
五级	专控保护级	需备案	更频繁	国家安全

"第二级以上需要强制测评" → 错！第三级以上才需要。"等级保护共分三级" → 错！五级。

☁️云原生六大技术

技术	说明	场景关键词
容器化	Docker等，应用打包隔离运行	环境不一致
微服务	单体拆分为独立部署的小服务	一个故障拖垮整体
DevOps	开发运维一体化，CI/CD	发布需停机
服务网格	Istio等，微服务间通信管理	服务间调用复杂
不可变基础设施	容器镜像不可变，替换而非修改	配置漂移
声明式API	描述期望状态而非操作步骤	K8s编排

其他高频技术概念

概念	要点
CAP定理	一致性C、可用性A、分区容忍P，三者只能满足两个。分布式系统必选P，所以是在CA之间选。
BASE	Basically Available（基本可用）、Soft State（软状态）、Eventually Consistent（最终一致性）
绞杀者模式	单体→微服务迁移：新建微服务→路由切换→逐步替换→下线旧模块
Lambda vs Kappa	Lambda=批处理+流处理双通道；Kappa=只用流处理（简化版）
零信任	从不信任，始终验证；四大特性：身份认证、设备验证、最小权限、微隔离

🔐加密与数字签名

对称 vs 非对称加密

对称加密

同一把密钥加解密
✅ 速度快
❌ 密钥分发困难
代表：AES、DES、3DES

非对称加密

公钥加密、私钥解密
✅ 解决密钥分发
❌ 速度慢
代表：RSA、ECC

数字签名完整流程

发送方对消息做哈希（摘要）
用发送方的私钥加密摘要 → 签名
用接收方的公钥加密消息 → 保密
接收方用自己的私钥解密消息
用发送方的公钥解密签名 → 验证
对消息做哈希，与解密的摘要对比

先哈希再签名（不直接签名原文，签名摘要）。签名=私钥加密摘要，验证=公钥解密摘要。

密码存储

密码存储用加盐哈希（Salt+Hash），不是加密！加密可逆，哈希不可逆。

📝案例答题话术模板

架构风格对比答题模板

① 选择XX风格（结论）
② 优势：XX方面具有XX特点（如：事件驱动在实时性方面具有响应快的特点）
③ 劣势：XX方面存在XX不足
④ 适用场景：适合XX类型系统

扩展性/可修改性问法答题模板

① 定义标准接口（接口层抽象）
② 采用注册机制（插件注册发现）
③ 使用配置化/规则化方式（声明式扩展）
④ 具体技术：SPI机制、策略模式、观察者模式

案例三步法

结论：直接回答问题
具体技术名词+原理：用专业术语，不用通俗描述
逐条对应背景条件：把题目中的条件逐条回应（值2-3分）

常见失分原因：只写关键词不展开、不用专业术语、不对应题目背景条件。

分页地址转换公式

页号 = 逻辑地址 / 页面大小（整除）
页内偏移 = 逻辑地址 % 页面大小
物理地址 = 页框号 × 页面大小 + 页内偏移

页面4KB时十六进制快速法：页号=高位部分（去掉末3位hex），偏移=末3位hex

🧩内聚与耦合

七种内聚（从低到高，功能内聚最优）

类型	含义	类比
偶然内聚	几个功能硬凑在一起，毫无关联	随机分到一组的人
逻辑内聚	逻辑上相关的功能放一起，由参数决定执行哪个	同一类工具放一个抽屉
时间内聚	同一时间段执行的功能放一起	晨起流程：刷牙洗脸穿衣
过程内聚	按特定顺序执行的处理步骤放一起	按步骤的菜谱
通信内聚	操作同一数据集的功能放一起	都操作"学生表"的增删改查
顺序内聚	一个功能的输出是另一个的输入	流水线：A的产出给B
功能内聚	所有元素共同完成一个单一功能	只做一件事且做好

内聚从低到高：偶逻时过通顺功（偶然→逻辑→时间→过程→通信→顺序→功能）

七种耦合（从低到高，非直接耦合最优）

类型	含义	类比
非直接耦合	两模块无直接关系，通过主模块间接联系	互不认识，通过中间人联系
数据耦合	只通过简单数据参数传递信息	只传纸条不传原件
标记耦合	通过数据结构（记录/对象）传递信息	传整个档案袋
控制耦合	传递控制信息（开关/标志），一个模块控制另一个的执行	远程遥控器
外部耦合	共享外部数据格式/通信协议/设备	共用同一台打印机
公共耦合	共享全局数据结构/公共变量	共用一块白板
内容耦合	一个模块直接访问另一个模块的内部数据/代码	直接翻别人的抽屉

耦合从低到高：无数标控外公内（非直接→数据→标记→控制→外部→公共→内容）

考试陷阱："传递整个数据结构"是标记耦合不是数据耦合。数据耦合只传简单参数（int、string）。传递控制标志（flag/开关）是控制耦合。

🧪白盒测试 · 逻辑覆盖

六种覆盖强度排序（从弱到强）

语句覆盖 < 判定覆盖 < 条件覆盖 < 判定/条件覆盖 < 条件组合覆盖 < 路径覆盖

逐一详解

覆盖类型	要求	说明
语句覆盖	每条语句至少执行一次	最弱，只管"跑过"，连分支都可能没覆盖全
判定覆盖（分支覆盖）	每个判定的真假分支至少执行一次	覆盖了分支，但不管条件内部的各个子条件
条件覆盖	每个条件的真假至少取一次	管到每个子条件，但组合情况不一定覆盖
判定/条件覆盖	同时满足判定覆盖和条件覆盖	既覆盖分支又覆盖每个条件，但条件组合不一定全
条件组合覆盖	所有条件的真假组合至少出现一次	最强（除路径覆盖外），用例数最多
路径覆盖	覆盖程序中所有可能的执行路径	理论上最强，但路径数可能爆炸（循环导致无限路径）

快速判断技巧

题目问"最弱的覆盖" → 语句覆盖
题目问"保证每个条件真假都取到" → 条件覆盖
题目问"所有条件组合都要覆盖" → 条件组合覆盖
题目问"覆盖所有可能执行路径" → 路径覆盖
条件组合覆盖的用例数 = 2^n（n=条件个数），如2个条件→4个用例

条件覆盖 ≠ 判定覆盖。条件覆盖管每个子条件的真假，但可能出现：每个条件都取过真假，但判定结果只取了真没取假。所以二者独立，判定/条件覆盖是同时满足两者。

白盒 vs 黑盒 vs 其他

类型	方法	关注点
白盒测试	逻辑覆盖、路径分析	内部代码结构
黑盒测试	等价类划分、边界值分析、因果图	功能是否正确，不看代码
回归测试	修改后重新测试	确认修改没引入新bug

🧩设计模式速查（23种）

三大分类

创建型5 + 结构型7 + 行为型11 = 23种

类型	核心目的	包含模式
创建型	对象怎么创建	工厂方法、抽象工厂、单例、建造者、原型
结构型	类和对象怎么组合	适配器、桥接、组合、装饰器、外观、享元、代理
行为型	对象之间怎么交互	责任链、命令、解释器、迭代器、中介者、备忘录、观察者、状态、策略、模板方法、访问者

速记口诀

创建：工抽单建原 | 结构：适桥组装外享代 | 行为：责命解迭中备观状策模访

🏭创建型模式（5种）

模式	核心要点	适用场景
工厂方法	定义创建对象的接口，由子类决定实例化哪个类	不知道具体要创建哪个类的实例
抽象工厂	创建一系列相关对象的接口，无需指定具体类	需要创建产品族（如跨平台UI组件）
单例	确保一个类只有一个实例+全局访问点	配置管理、线程池、日志、数据库连接池
建造者	将复杂对象的构建与表示分离，分步骤构建	对象有很多可选参数（如SQL查询构建）
原型	通过复制已有实例来创建新实例（clone）	创建成本高，复制比new更高效

单例的懒汉式=第一次使用时创建（延迟加载）；饿汉式=类加载时就创建。考试经常考反。

🏗️结构型模式（7种）

模式	核心要点	适用场景
适配器	将一个类的接口转换为客户端期望的另一个接口	兼容旧接口、整合第三方库
桥接	将抽象部分与实现部分分离，使它们可以独立变化	避免多层继承爆炸（如形状×颜色）
组合	将对象组合成树形结构，统一处理单个对象和组合对象	文件系统、菜单树、组织架构
装饰器	动态地为对象添加额外职责，不修改原有类	Java IO流、为对象加功能但不想改原类
外观	为子系统提供一个统一的高层接口	简化复杂子系统的调用（如一键下单）
享元	共享细粒度对象，减少内存用量	大量相似对象（如字符编辑器中的字符对象）
代理	为其他对象提供代理以控制对它的访问	远程代理、虚拟代理、保护代理、缓存代理

装饰器 vs 代理

装饰器：增强功能，不改变接口
代理：控制访问，可能改变行为

适配器 vs 桥接

适配器：事后补救，让不兼容的接口能一起工作
桥接：事前设计，将抽象与实现分离

🎯行为型模式（11种 · 高频6种）

模式	核心要点	适用场景
观察者高频	一对多依赖，对象状态变化时自动通知所有观察者	事件监听、消息推送、MVC中的Model-View
策略高频	封装算法族，使它们可以互相替换	排序算法切换、支付方式选择、折扣计算
模板方法高频	定义算法骨架，将某些步骤延迟到子类实现	框架设计（如JUnit的setUp/tearDown）
命令高频	将请求封装为对象，支持撤销、队列、日志	撤销/重做操作、任务队列、宏命令
状态高频	允许对象在内部状态改变时改变其行为	订单状态机、审批流程、游戏角色状态
责任链高频	将请求沿链传递，直到有对象处理它	审批流程（员工→经理→总监）、异常处理链
迭代器	提供顺序访问聚合对象元素的方法，不暴露内部	遍历集合对象
中介者	用中介对象封装多个对象之间的交互	聊天室、航空管制、GUI组件协调
备忘录	在不破坏封装的前提下捕获和恢复对象内部状态	撤销操作、存档/读档
解释器	为语言定义文法表示，并设计解释器解释语句	正则表达式、SQL解析、数学表达式求值
访问者	在不修改元素类的前提下定义新操作	编译器AST遍历、文档导出（PDF/HTML）

策略 vs 状态

策略：客户端主动选择算法
状态：对象自动切换行为（状态变了行为就变）

观察者 vs 中介者

观察者：一对多通知（发布-订阅）
中介者：多对多协调（中心化通信）

命令模式 vs 策略模式：命令封装的是"请求/操作"（可撤销、可排队），策略封装的是"算法/行为"（可替换）。考试常混淆。

📐SOLID原则（设计模式基础）

原则	全称	含义
S	单一职责原则	一个类只有一个引起它变化的原因
O	开闭原则	对扩展开放，对修改关闭
L	里氏替换原则	子类可以替换父类出现的地方
I	接口隔离原则	客户端不应依赖它不需要的接口
D	依赖倒置原则	高层不依赖低层，都依赖抽象

口诀：单开里接依（单开里接衣）

依赖倒置 ≠ 依赖注入。依赖倒置是原则（都依赖抽象），依赖注入是实现方式（由外部注入依赖）。

🎯案例题高频考法

考法1：选择合适的设计模式

题目关键词 → 模式：
"动态添加职责" → 装饰器
"接口不兼容/转换" → 适配器
"封装请求/撤销" → 命令
"一对多通知" → 观察者
"算法可替换" → 策略
"状态改变行为" → 状态
"统一高层接口" → 外观
"树形结构" → 组合
"控制访问" → 代理

考法2：对比两种模式的区别

答题模板：
① 模式A的核心是XX，适用于XX场景
② 模式B的核心是XX，适用于XX场景
③ 本题场景是XX，应选XX模式

📊排序算法速查（8种）

总览对比表

算法	最好	平均	最坏	空间	稳定
冒泡排序	O(n)	O(n²)	O(n²)	O(1)	✅
选择排序	O(n²)	O(n²)	O(n²)	O(1)	❌
插入排序	O(n)	O(n²)	O(n²)	O(1)	✅
希尔排序	O(n log n)	O(n^1.3)	O(n²)	O(1)	❌
快速排序	O(n log n)	O(n log n)	O(n²)	O(log n)	❌
归并排序	O(n log n)	O(n log n)	O(n log n)	O(n)	✅
堆排序	O(n log n)	O(n log n)	O(n log n)	O(1)	❌
基数排序	O(d(n+r))	O(d(n+r))	O(d(n+r))	O(n+r)	✅

稳定的：冒插归基（冒泡、插入、归并、基数）

稳定性辨析（高频考点）

选择排序不稳定：例 [5, 8, 5, 2, 9]，第一趟选最小值2与第一个5交换，两个5的相对顺序改变。
快速排序不稳定：partition过程中相等元素可能被交换到不同侧。
堆排序不稳定：堆调整过程中相等元素的相对位置可能改变。

简单记忆：O(n log n)的四个算法中，只有归并排序是稳定的。

🔍各算法核心要点

冒泡排序

相邻元素两两比较，每趟把最大值"冒"到末尾。最好O(n)（已有序，一趟就停），最坏O(n²)（逆序）。

选择排序

每趟从剩余元素中选最小值放到已排序末尾。不稳定，比较次数始终为n(n-1)/2，与初始顺序无关。

插入排序

将元素插入到已排序序列的正确位置。最好O(n)（已有序），最坏O(n²)（逆序）。小规模数据或基本有序时效率高。

希尔排序

缩小增量的插入排序。先按大间隔分组做插入排序，逐步缩小间隔。平均O(n^1.3)，不稳定。

快速排序

选基准值(pivot)，partition分为左右两部分，递归排序。平均O(n log n)，最坏O(n²)（已有序+选首元素为基准）。空间O(log n)（递归栈）。

快排最坏情况：数组已有序+选第一个元素为基准→退化为O(n²)。优化：三数取中法选基准。

归并排序

分治法：拆成两半分别排序，再合并。时间始终O(n log n)（最好最坏都一样），空间O(n)（需要辅助数组）。唯一稳定的O(n log n)排序。

堆排序

建大顶堆+反复取堆顶+调整。时间始终O(n log n)，空间O(1)。不稳定。适合大数据量+空间受限场景。

基数排序

按位分配收集：从最低位到最高位，每轮用稳定排序（如计数排序）。时间O(d(n+r))，d=位数，r=基数。适合整数/字符串排序。

🎯排序算法选择（案例题考法）

场景选型

场景	推荐算法	理由
数据量小（n≤50）	插入排序	简单、常数因子小、稳定
数据基本有序	插入排序	最好O(n)
数据量大、随机分布	快速排序	平均性能最优
需要稳定排序+大数据量	归并排序	唯一稳定的O(n log n)
空间受限、不要求稳定	堆排序	O(1)空间
整数且范围不大	基数排序/计数排序	可达到O(n)
外部排序（数据在磁盘）	归并排序	顺序访问，适合磁盘IO

易混对比

快速排序 vs 归并排序

快排：先partition再递归，不稳定
归并：先递归再合并，稳定
快排空间O(log n)，归并空间O(n)

堆排序 vs 快速排序

堆排：最坏也是O(n log n)，空间O(1)
快排：最坏O(n²)，但平均更快
堆排不稳定，快排也不稳定

考试陷阱："平均性能最好的排序"→快排。"最坏情况下仍为O(n log n)"→归并/堆排。"稳定的O(n log n)排序"→只有归并。

📄论文万能模板 v4 · 无人机智能管控平台

项目信息速查

项目	某地市电力公司输配电无人机智能管控平台
投资	315万
时间	2024年6月立项 → 2025年4月上线（已运行13个月）
角色	系统架构设计师
团队	15人（架构师1+后端5+前端2+算法3+测试2+运维2）

✍️摘要（200字 · 固定+填充）

2024年6月，我参与了某地市电力公司输配电无人机智能管控平台项目的建设，担任系统架构设计师，负责系统整体架构设计与技术选型。该平台用于替代传统人工巡检方式，实现无人机自主巡检、三维点云解析、航线自动规划、缺陷智能识别及巡检任务闭环管理。项目团队共15人，总投资315万元，于2025年4月上线运行。在本项目中，我重点采用了【技术/架构】，围绕【关键词】进行了深入的架构设计与技术选型。通过【核心技术手段】，系统在性能、可用性和可扩展性等方面均达到了设计目标。上线至今系统稳定运行，日均处理巡检数据超过200GB，巡检效率较传统方式提升约60%，得到了用户的高度认可。

填充实例

题目方向	技术/架构	关键词	核心手段
微服务/SOA	微服务架构	服务拆分与治理	服务注册发现、API网关、消息队列异步通信
分布式	分布式架构	节点协作与数据一致性	任务调度中心、多副本冗余、心跳故障检测
大数据	大数据处理架构	海量巡检数据的存储与计算	分布式文件存储、并行计算、分层数据处理
可靠性	高可用架构	系统可靠性保障	冗余部署、故障自动转移、熔断降级

📋第一部分：项目概述（500字 · 完全固定）

项目背景

在电力行业中，输配电线路的安全稳定运行直接关系到电力系统的整体可靠性。传统人工巡检方式存在效率低、安全风险高、覆盖范围有限等问题，特别是在山区、高塔及复杂地形区域，巡检人员需攀爬铁塔或穿越丛林，人身安全难以保障。随着无人机技术和三维点云技术的发展，通过无人机对输电线路进行自动化巡检已成为行业发展趋势。

然而，无人机巡检产生的数据量巨大——单次巡检可生成数十GB的点云与影像数据，且巡检任务涉及航线规划、数据采集、点云解析、缺陷识别、结果派发等多个环节，各环节之间存在复杂的数据流转和业务协同需求。传统单体架构在处理这类海量、多模态、高并发的数据处理场景时，面临性能瓶颈、模块耦合度高、扩展困难等突出问题。为此，电力公司决定建设一套新型的无人机智能管控平台，以实现巡检业务的全流程数字化和智能化。

我的主要工作

作为该项目的系统架构设计师，我在项目全过程中承担了以下主要工作：

（1）需求分析与质量属性定义（2024年7-9月）：我与电力公司运维部门进行了为期两个月的需求调研，走访了3个巡检班组，梳理出15项核心业务需求和6项非功能性质量属性需求（性能、可用性、可扩展性、可修改性、安全性、可维护性），并将其量化为具体的设计指标。

（2）架构设计与技术选型（2024年9-11月）：我主导完成了系统总体架构设计，包括技术选型、服务拆分策略、通信机制、数据存储方案和部署架构。在架构评审中，我组织团队对两种候选架构方案进行了对比分析，基于质量属性需求做出了最终决策。

（3）开发协调与技术攻关（2024年11月-2025年3月）：在开发阶段，我负责架构决策的落地指导和技术难点的攻关。针对点云解析性能不足、服务间数据不一致等问题，我组织了多次技术研讨并提出了解决方案。

（4）测试与上线（2025年3-4月）：我主导制定了系统集成测试方案和灰度上线策略，系统于2025年4月上线后稳定运行至今。

📖第二部分：理论分析（400字 · 背1-2个模块）

建议首选背模块B（覆盖6个方向），再背模块C作为备用（覆盖4个方向）。两个模块覆盖全部11个方向。

模块B：微服务/SOA（最通用 ⭐）

面向服务架构（SOA）是一种将业务功能划分为独立服务单元的架构方法，通过标准接口和协议实现服务间的松耦合协作。SOA的核心原则包括：服务自治（每个服务独立部署和演进）、接口标准化（统一的通信协议和数据格式）、松耦合（服务间依赖最小化）、服务可重用（通用服务可被多个业务流程调用）。微服务架构是SOA的进一步演进，强调更细粒度的服务拆分、独立的数据存储和去中心化的治理。其关键技术包括服务注册与发现、API网关、负载均衡、熔断降级、分布式配置中心等。相较于传统单体架构，微服务在可扩展性、可维护性和技术栈灵活性方面具有显著优势，但也引入了服务间通信、数据一致性和运维复杂度等新的挑战。

适用方向：微服务、SOA、云原生、系统安全性、自动化测试、大部分通用题目（6个方向）

模块C：大数据处理

大数据处理是指对海量、多源、异构数据进行采集、存储、计算和分析的技术体系。其核心特征可用"5V"概括：Volume（数据量大）、Velocity（处理速度快）、Variety（数据类型多样）、Value（价值密度低）、Veracity（数据真实性）。关键技术包括：分布式存储（如HDFS、对象存储）实现数据的分块冗余存储；分布式计算（如MapReduce、Spark）实现多节点并行处理；流式计算实现实时数据处理。在架构设计中，需要根据数据特征和业务需求选择合适的存储和计算方案，在性能、成本和一致性之间做出权衡。湖仓一体（Lakehouse）是近年的重要发展方向，融合了数据湖的灵活存储和数据仓库的事务一致性，通过统一存储层实现ACID事务支持和Schema管理。

适用方向：大数据处理、湖仓一体、AI/智能化、数据库设计（4个方向）

模块A：分布式系统（备用）

分布式系统是由多台通过网络互联、协同完成任务的计算机节点组成的系统，对外呈现统一的逻辑整体。其核心特征包括：节点自治性（各节点独立运行）、操作透明性（用户无需感知数据分布）、资源共享（跨节点的资源访问）。分布式系统面临三大挑战：一是性能挑战，网络通信延迟和数据分布导致响应时间增加，需通过缓存、并行计算和负载均衡优化；二是可用性挑战，节点故障可能导致服务中断，需通过冗余部署和故障检测保障；三是一致性挑战，CAP定理指出一致性、可用性和分区容忍性三者不可兼得，需根据业务场景在强一致性和最终一致性之间权衡。

模块E：系统可靠性（备用）

系统可靠性是指系统在规定条件下和规定时间内完成功能的能力。核心指标包括：MTTF（平均无故障时间）、MTTR（平均修复时间）、可用性=MTBF/(MTBF+MTTR)。提升可靠性的主要策略包括：冗余设计（多副本部署消除单点故障）、故障检测（心跳机制、健康检查）、故障恢复（自动转移、熔断降级、限流）、容错设计（重试机制、补偿事务、幂等性保障）。可靠性需要在成本和可用性之间权衡——更高的可靠性意味着更多的冗余资源和更复杂的运维。

🔧第三部分：技术方案（200字 · 选1个）

默认用方案A，只有题目明确要求大数据/可靠性/云原生时才换方案B/C/D。

方案A：服务拆分与通信（万能 ⭐）

在本项目中，我将系统按业务领域拆分为五个独立服务：点云处理服务、杆塔通道解析服务、航线规划服务、图像回传服务和数据流转派发服务。每个服务拥有独立的数据库和接口定义，遵循"高内聚、低耦合"原则。服务间同步通信采用RESTful API（如/api/v1/pointcloud/upload），异步通信采用RabbitMQ消息队列。选择RESTful而非gRPC，是因为团队对HTTP更熟悉，且本系统的性能瓶颈在点云计算而非服务通信。通过服务注册中心实现动态服务发现，新增节点只需注册即可加入集群。

适用：微服务、SOA、分布式、大部分题目

方案B：分布式任务调度与容错

在本项目中，我设计了基于任务调度中心的分布式任务管理方案。调度中心采用"最小负载优先"策略，根据节点CPU、内存和当前任务数进行智能分配。通过心跳机制（每5秒一次）监控节点状态，节点失联超过30秒自动触发任务迁移。关键服务部署至少2个实例，消除单点故障。数据存储采用多副本策略，保障数据可靠性。系统整体可用性达99.7%。

方案C：大数据处理架构

在本项目中，我设计了分层数据处理架构。原始数据层存储无人机采集的点云和影像，采用分布式文件系统实现高吞吐读写。处理层采用并行计算框架，将点云按空间区域分块分配至多节点同时处理。结果层将解析后的结构化数据存储至关系型数据库，支持业务查询和报表分析。通过消息队列连接各层，实现数据异步流转和最终一致性。

方案D：容器化部署

在本项目中，我将各服务以Docker容器形式打包，通过Kubernetes编排管理。通过HPA机制根据CPU使用率自动调整实例数。服务更新采用滚动发布策略，新版本逐步替换旧版本，避免整体停机。容器化实现了环境一致性，消除了"在我机器上能跑"的问题。

💡第三部分：问题故事（300字 · 选2个）

故事1：点云解析性能瓶颈（万能 ⭐）

开发初期，单节点解析10GB点云文件需约2小时，远超用户期望的30分钟。我分析后发现瓶颈在单线程串行处理和频繁磁盘IO。我决定采用两个优化策略：一是引入并行计算框架，将点云按空间区域分块分配至4个节点同时解析；二是引入内存缓存减少重复IO。优化后解析时间缩短至25分钟，满足性能要求。这让我认识到架构设计必须以实际性能数据为依据，而非凭经验假设。

适用：性能、大数据、分布式、大部分题目

故事2：服务间数据不一致（万能 ⭐）

上线初期偶尔出现点云解析完成但派发服务未收到通知的情况，排查发现是消息队列高负载时消息丢失。我采取两个措施：一是消息队列开启持久化和消费确认机制；二是引入补偿任务定时扫描未同步数据并重新派发。实施后数据丢失率从0.3%降至0，任务调度成功率从98%提升至99.5%。这让我认识到分布式系统中不能假设任何通信可靠，必须设计容错和补偿机制。

适用：分布式、可靠性、数据管理、大部分题目

故事3：微服务拆分粒度争议（备用）

架构评审中团队对"图像回传"和"AI缺陷识别"是否合并产生分歧。我最终决定拆分，理由是AI模型迭代频率远高于图像回传模块，拆分后可独立升级；且未来可能接入多种AI模型，拆分后扩展更灵活。上线后AI模块3个月内迭代了4个版本而图像回传服务保持稳定，验证了这一决策的正确性。

故事4：安全性与性能的权衡（备用）

电力公司要求所有数据传输加密，但全量加密数十GB点云数据会导致传输时间增加约40%。我分析后发现点云原始数据不包含敏感信息，真正敏感的是解析后的杆塔位置。因此采用分层加密策略——原始数据不加密（内网环境），结构化结果TLS加密，敏感数据AES-256加密存储。既满足安全要求，又将性能影响控制在5%以内。

📊实施效果 + 总结（300字 · 完全固定）

实施效果（100字）

系统于2025年4月上线至今稳定运行，取得以下成效：日均处理巡检数据超过200GB，整体数据处理速度提升约3倍；平台可用性达99.7%，任务调度成功率超过98%；巡检效率提升约60%，人工成本降低近三分之一；模块化设计使得单个服务可独立升级，版本迭代周期从两周缩短至三天。

第四部分：总结（200字）

本项目通过采用【题目要求的技术/架构】，有效解决了传统单体架构在性能、扩展性和维护性方面的不足。在设计过程中，我始终以质量属性需求为驱动，通过【技术手段1】和【技术手段2】等策略，实现了系统的高可用、高扩展与高性能目标。

当然，项目也存在一些不足之处。例如，在系统监控方面，初期仅实现了基础的心跳检测，缺乏完善的链路追踪和性能监控体系，后续通过引入可观测性工具进行了补全。这也让我认识到，架构设计是一个持续演进的过程，需要在实践中不断优化和完善。

未来，我将继续关注【题目相关技术领域】的发展，持续提升自身的架构设计能力，为后续项目提供更优质的技术方案。

🗺️题目 → 组装速查表

论文方向	第二问	第三问
分布式系统	模块A	方案A+B + 故事1+2
微服务架构	模块B	方案A+D + 故事3+1
SOA	模块B	方案A+D + 故事3+1
大数据处理	模块C	方案C+A + 故事1+2
湖仓一体	模块C	方案C+A + 故事2+1
云原生	模块B	方案D+A + 故事1+3
系统可靠性	模块E	方案B+D + 故事2+1
系统安全性	模块B	方案A+故事4+2
自动化测试	模块B	方案A+D + 故事3+1
AI/智能化	模块C	方案C+A + 故事1+3
数据库设计	模块C	方案C+故事2+4

第一问和总结完全固定，第二问背模块B+C覆盖全部方向，第三问方案A+故事1+2万能适配。

🛡️完全陌生题目的保底策略

第一步：选题

4个题目里一定有一个和你的项目沾点边。优先选涉及"架构设计""系统设计""数据处理""服务化"关键词的。

第二步：第一问完全用固定内容

项目背景+我的工作，一字不改直接写。

第三步：第二问用质量属性框架现编

"【题目技术】的核心目标是满足系统的XX、XX和XX等质量属性需求。从性能角度看，该技术通过XX手段提升系统响应速度和吞吐量；从可用性角度看，该技术通过XX机制保障系统的持续运行；从可扩展性角度看，该技术通过XX方式支持系统的弹性扩展。此外，该技术还需关注安全性、可维护性等质量属性，在设计中需要做出合理的权衡。"

第四步：第三问用方案A+故事1+故事2

不管什么题目，方案A（服务拆分）都能用。故事1（性能优化）和故事2（数据不一致）也是万能的。

第五步：总结用固定句式

按此保底策略，即使完全陌生的题目也能写出2000字，预估45-52分，刚好过线。

💬万能句式

"为满足系统的【XX】质量属性需求，我在架构设计中采用了【XX技术】，而非【XX方案】，主要基于以下考虑：【理由1】和【理由2】。"
"在实际运行中，该策略取得了良好效果——【具体数据指标】，验证了架构决策的合理性。"
"在【XX】与【XX】之间，我进行了权衡分析。考虑到项目【XX约束】，最终选择了【XX方案】。"
"针对【XX问题】，我的解决方案是【XX】，在实际应用中取得了【XX效果】。"
"当然，项目也存在一些不足。例如【XX方面】还有改进空间，后续通过【XX方式】进行了优化。"

⭐质量属性 → 技术策略速查

质量属性	题目关键词	技术策略
性能	响应时间、吞吐量、并发	缓存、并行计算、GPU加速、异步消息队列、负载均衡
可用性	不中断、故障恢复、高可靠	多副本部署、心跳检测、故障自动转移、熔断降级
可扩展性	新增模块、弹性伸缩	微服务拆分、服务注册发现、容器化、水平扩展
可修改性	独立升级、不影响其他	接口抽象、信息隐藏、配置化
安全性	数据安全、访问控制	TLS/AES加密、RBAC、Token认证、审计日志
可维护性	运维便利、日志监控	容器化、统一日志、链路追踪

⏱️考场写作顺序

步骤	内容	用时
1	写摘要（看题目确定占位符）	10分钟
2	写第一部分（完全固定，直接默写）	20分钟
3	写第二部分（选理论模块）	15分钟
4	写第三部分（选方案+故事+效果）	30分钟
5	写总结	10分钟
6	检查字数和逻辑	5分钟

总计约90分钟，留30分钟缓冲。目标2500字以上。

背诵优先级

第一优先：摘要固定段 + 第一部分（700字）→ 考场直接默写
第二优先：模块B理论（250字）→ 覆盖6个方向
第三优先：方案A + 故事1+2（500字）→ 万能组合
第四优先：第四部分总结（200字）→ 固定句式
选背：模块C理论（250字）→ 覆盖大数据/AI/数据库

🔭Kruchten 4+1 视图模型

五个视图总览

视图	关注点	对应UML图	使用者
逻辑视图	功能需求、领域模型、"做什么"	类图、对象图、状态图	最终用户
进程视图	并发、同步、运行时、"怎么运行"	活动图、序列图、通信图	系统集成者
开发视图	模块划分、代码结构、"怎么组织代码"	包图、组件图	程序员
物理视图	软件→硬件映射、"怎么部署"	部署图	系统工程师
场景视图(+1)	用例驱动，串联验证其他四个	用例图	所有利益相关者

速记：逻做什、进怎么跑、开怎么码、物怎么装、场串起来

静态 vs 动态

静态结构

逻辑视图、开发视图
描述系统的结构组成

动态结构

进程视图、物理视图
描述系统的运行与部署

"物理视图"也叫"部署视图"，是同一概念的不同译法。"开发视图"也叫"实现视图"。

别混淆Hofmeister四视图（概念/模块/执行/代码），与Kruchten的4+1不同！

⚖️法律法规与知识产权

六大知识产权类型

类型	取得方式	保护期限	续展
著作权	自动取得	作者终生+50年；单位发表后50年	不可
发明专利	申请+实质审查	20年（自申请日）	不可
实用新型/外观设计	申请+形式审查	10年（自申请日）	不可
商标权	需注册	10年（自核准注册日）	可以，每次10年，次数不限
商业秘密	自动保护（需保密措施）	无固定期限	--

发明20实用10，商标10年可续展，著作权自动保50，商业秘密无期限

软件著作权归属（高频！）

场景	无约定时归属
职务开发（本职工作）	归单位
非职务开发（个人）	归开发者个人
委托开发	归受托人（实际开发者）
合作开发	共同享有

委托开发无约定时归受托人（开发者），不是出资的委托方！出资≠有著作权。

"必须登记才能获得著作权"→错！著作权自软件开发完成之日起自动产生。

软件著作权的权利

类别	权利	保护期
人身权	发表权	50年
	署名权（开发者身份权）	永久
	修改权	永久
	保护作品完整权	永久
财产权	使用权、复制权、发行权、出租权、翻译权、转让权等	50年

发表权是人身权但有50年期限；署名权、修改权才是真正永久的。

专利申请原则

先申请原则（不是先发明！）| 单一性原则 | 书面原则

中国专利采用"先申请原则"。两人同日申请→协商确定。商标采用"先注册原则"。

合理使用（不构成侵权）

以下可不经许可、不付报酬（但需指明作者）：
① 个人学习、研究或欣赏
② 课堂教学或科学研究（少量复制）
③ 国家机关执行公务
④ 新闻报道中不可避免地引用
⑤ 为介绍/评论某一作品而适当引用
⑥ 免费表演（未收费也未付报酬）
⑦ 翻译成少数民族语言文字在国内出版

侵权判断速判

情形	结果	理由
个人学习复制一份	不侵权	合理使用
课堂教学少量复制	不侵权	合理使用
企业内部用盗版软件	侵权	非个人学习
独立创作相同作品	不侵权	独立创作≠抄袭
个人学习但放到网上传播	侵权	超出合理使用
保护期满后使用	不侵权	进入公共领域（仍需署名）

商业秘密四要件

秘密性 + 价值性 + 实用性 + 保密性

商业秘密泄密即丧失保护。一旦公开，不再构成商业秘密。