用四个格子看懂系统：区块链系统评价的四个维度

学区块链之前，先学会“怎么拆一台机器”。本课不涉及任何区块链的技术细节，它给的是一套观察系统的语言——后面所有内容都要靠这套语言来定位“某件事到底属于哪一层、哪一面”。

1. 核心问题

你和朋友聊同一部手机，他说“信号不好”，你说“微信发不出去消息”，两个人吵了十分钟，最后发现说的根本不是一回事。

根本痛点：人面对复杂技术系统时，脑子里的“切分方式”是各切各的、高度私人化的。 哪些算重要、哪些可以忽略，取决于个人的偏好、具体技术本身，以及各自的目标和使用经验。于是同一样东西，你心里划的那条线和我心里划的那条线不在同一个位置——沟通必然错位。

这一课要解决的就是：找到一种标准、统一、可复用的切法，把任何软件系统拆成少数几个格子，让所有人指着同一个格子说同一句话。

一句话概括：先学会拆系统，才学会评价系统。

2. 生活化比喻与通俗案例

比喻一：手机——你其实“只用了它的一小层”

你手里那部手机，工作时其实叠着一大摞东西：

电磁波（Electromagnetic Wave）怎么承载移动通信的信号
无线通信协议（Wireless Communication Protocol）怎么把数据发送出去、接收回来
应用层（Application Layer）怎么把一堆像素画成你朋友的脸

你的实际知识储备：大概率一条都说不清。但你照样会打电话、发微信、拍照。

这说明一件非常重要的事：人在使用技术时，会本能地把系统在心里“切成两半”——需要知道的那半（怎么拍照），和可以放心忽略的那半（电磁波怎么传）。 这种心理切分不是偷懒，而是人应对复杂技术时常用的一种办法。学新电视、新电脑、新洗衣机，用的都是同一套本能。

比喻二：切法不统一会造成沟通灾难

关键问题来了：你的那两半，和我的那两半，界线画在不同地方。

你买手机关心的是“拍照好不好看”，所以你的分界线画在“相机算法”以上。
通信工程师买同一部手机，分界线画在“天线和无线通信”以上，他觉得屏幕上的应用只是“上面的部分”。
产品经理的分界线又画在“用户看到的界面和操作”这一层。

于是当两个人讨论“这部手机好不好”时，一个在讲上层格子，一个在讲下层格子，双方都以为自己赢了，其实根本没交上手。

这就是为什么“如何切分系统”必须先谈妥——教技术、讨论技术，第一件事不是讲知识点，而是先统一坐标系。

比喻三：餐厅点菜——“点什么”和“点得爽不爽”是两回事

你点了一道“宫保鸡丁” → 这是**功能性（Functional Aspect）**问题（你要系统“做什么”）。
你要求“上菜要在 10 分钟内、菜不能凉、结账别排长队、我的会员手机号别泄露给推销的” → 这是**非功能性（Non-Functional Aspect）**问题（系统“做得怎么样”）。

菜上来了但用了 2 小时：菜是对的（功能满足），体验崩了（非功能不满足）。 这两件事完全可以互相独立地好坏，所以必须分开检查。

比喻四：菜单 vs 后厨——“用户的需求”和“让它发生的技术”

菜单上写的：宫保鸡丁、鱼香肉丝 → 这是应用层（Application Layer），用顾客的语言描述“你能得到什么”。
后厨里的：切配、火候、煤气阀门、排烟管道 → 这是实现层（Implementation Layer），全是技术细节，顾客看不见也不需要看见，它存在的唯一理由就是“让菜单上的东西真的能端出来”。

一个顾客完全可以对着菜单点菜，一句后厨的事都不懂。反过来说，如果有一天后厨的排烟管道堵了，顾客的直观感受只是“今天菜有股怪味”——他感知到的永远是后果，而不是原因。

把上面四个比喻压缩成一句话，就是本课的心智模型：

任何系统都可以用“两把刀”来切：一把横着切（应用层 / 实现层），一把竖着切（功能性 / 非功能性）。切完得到四个格子，每个格子的问题都必须待在原地被讨论，不许串门。

3. 核心原理解析

3.1 为什么“必须切”：复杂度是硬的，人的脑容量是软的

一个软件系统往往包含大量彼此协作的部分，人的注意力却有限。把系统分开，才更容易理解和使用。

但“随便切”不行——随便切出来的分界线只属于你自己，一沟通就崩。所以需要的不是“能切”，而是一种大家公认的、和产品形态无关的切法。

常见的几种切法为什么都不够用：

常见切法	问题在哪
按“功能模块”切（相机模块、聊天模块）	只覆盖“做什么”，完全无处安放“快不快”“安全不安全”这类问题
按“开发分工”切（前端组、后端组）	组织结构的产物，随团队变动而变，不是系统本身的属性
按“重要程度”切（重要的、不重要的）	主观，两个人打分永远不一样，等于没切

结论：我们需要两条彼此独立的轴，一条管“面向谁”，一条管“是关于什么类型的问题”。

3.2 第一把刀：应用层 vs 实现层

划分依据：这一部分东西是为“用户的需求”存在，还是为“让需求得以实现”存在。

应用层（Application Layer）：一切关乎用户需求的要素，是系统的目的。
- 例子：听音乐（Listening to Music）、拍照（Taking Photos）、预订酒店房间（Booking a Hotel Room）。
- 语言特征：用用户的日常词汇就能描述清楚，不需要任何技术背景。
实现层（Implementation Layer）：一切“让这些需求真的发生”的要素。
- 例子：把数字信息转换成声学信号（Converting Digital Information into Acoustic Signals）、识别数码相机里某个像素的颜色（Recognizing the Color of a Pixel）、通过互联网向预订系统发送报文（Sending Messages over the Internet）。
- 语言特征：本质上是技术性的，并且在概念上只是手段（Means to an End）——它自己不是目的，它存在的唯一合法性就是服务于上层的某个需求。

推导：为什么这条线这么重要？

因为评价标准完全不同。对应用层，核心问题是“这是不是用户想要的”；对实现层，问题是“这样做能不能达成上层目标、代价多大”。

一旦把这两层混在一起讨论，就会出现经典的灾难：“我用得挺好啊，凭什么说它有 Bug？” 和 “你懂不懂技术啊，这里面全是巧思！”——前者站在应用层，后者站在实现层，两个人永远吵不完。这条线的作用，就是让争吵可以中止：先说清你在哪一层，再谈好坏。

3.3 第二把刀：功能性 vs 非功能性切面

划分依据：这一条讲的是“系统做什么”，还是“系统把这件事做得怎么样”。

功能性切面（Functional Aspect）：系统执行的动作本身。
- 例子：通过网络发送数据、播放音乐、拍照、修改图片里的某个像素。
非功能性切面（Non-Functional Aspect）：动作执行的方式、质量、约束。
- 例子：图形用户界面（Graphical User Interface, GUI）看起来漂亮、软件运行速度快、用户数据保持私密与安全。
- 另外两项重量级的非功能性切面是安全性（Security）和完整性（Integrity）——本课后面 3.6 部分专门深挖完整性。

记忆技巧（英语词性类比）：功能性 ≈ 动词（Verb），非功能性 ≈ 副词（Adverb）。

一个人可以走得快（walk fast），也可以走得慢（walk slowly）。
“走路”这个动作在两句里完全一样，变的只是“怎么走”。
所以：软件“能发消息”是动词；“消息发得快不快、发得安不安全”是副词。

推导：为什么要专门把“副词”单列成一条轴？

因为软件项目里很多让人暴怒的失败，不是动词没做到，而是副词做砸了。

需求文档特别容易只写动词（“系统必须支持转账”），因为动词好写、好验收——功能做没做出来，点一下就知道。而副词（“转账要快速完成、要防篡改、要保护隐私、要能在大量用户同时在线时保持稳定”）通常没人认真定义，也没法在验收会上“点一下”就确认。于是它们长期处于“默认存在、无人负责”的状态，直到线上事故那天才现出原形。

举个更扎心的例子：一款记账 App 的所有功能都实现了，账单也能导出，老板验收时非常满意。上线三个月后用户开始流失，理由是“每次点开要转五秒圈”。功能一个没少，产品却死了——杀死它的不是动词，是副词。

把非功能性提升为一条独立的轴，本质是逼着团队把“副词”当成正式需求来对待，而不是留到出事后当成“性能优化”临时抱佛脚。

3.4 两把刀同时用：四象限分离矩阵

这两次切分是互相独立的：知道某个要素位于哪一层，推不出它是功能性还是非功能性。所以两把刀可以叠加，得到一张 2 × 2 的分离矩阵（Separation Matrix）。

以一部智能手机为例：

	功能性切面（做什么 / 动词）	非功能性切面（做得怎样 / 副词）
应用层（用户的需求）	• 拍照 • 打电话 • 发邮件 • 浏览网页 • 发送聊天消息	• 图形界面看起来漂亮 • 容易上手 • 消息发送得快
实现层（让它发生）	• 在设备内部保存用户数据 • 连接最近的移动通信接入点 • 访问数码相机里的像素	• 以节省空间的方式存储数据 • 节省电量 • 维持完整性（Integrity） • 保障用户隐私

四个最容易归错的例子（先自己判一遍，再看答案）

一句话描述	正确归位	为什么
用户在聊天软件里点“发送”给好友发文字	应用层 × 功能性	这是用户的目的本身，且是个动作
操作系统把待处理数据压缩后写入固态硬盘	实现层 × 功能性	它是动作（写盘，动词），只是用户看不见——最容易错的一格
登录界面色彩搭配让人舒服	应用层 × 非功能性	面向用户的感受，且描述的是“做得怎样”
系统能抵抗恶意入侵并保持数据一致	实现层 × 非功能性	纯技术内部的品质约束（完整性 + 安全性）

第二行是全篇最高频的错误点：“用户看不见” ≠ “非功能性”。看不看得见是由“层”决定的，动作还是品质是由“切面”决定的，两件事各归各的轴。

3.5 从矩阵里读出真正的规律：可见性梯度

这张表不只是分类游戏。两端可以明确判断：左上格（应用层 × 功能性）最显眼，它是用户会主动学习、经常谈论的东西；右下格（实现层 × 非功能性）最容易被当作理所当然（Taken for Granted）。中间两格没有单独下结论，但可以顺着同一套逻辑推演出来。

格子	可见程度	通常表现
应用层 × 功能性	极显眼	用户会主动学习、经常谈论：“我要拍照、我要发消息”
应用层 × 非功能性	较显眼（推演）	用户能感到顺不顺手，但通常说不清背后的机制
实现层 × 功能性	通常看不见（推演）	用户一般不会主动注意这些动作
实现层 × 非功能性	被当作理所当然	正常时很少有人注意，出问题时才会被集中追问

表象与地基的分野就在这里：用户接触最多的是应用层功能（转账、聊天、拍照），但系统能否长期可靠运行，很大程度上取决于深埋底层、用户根本想不到的那些非功能特性（省电、省空间、隐私、完整性）。

这也说明了一个常被忽略的现象：软件专业人士会把大量工作时间投入实现层中那些不太显眼的非功能性细节。这些工作平时不容易被注意，却是系统可靠运行所需要的持续投入。

3.6 重点深挖：完整性——右下格里看似很小、却极费功夫的东西

完整性是软件系统的一项重要非功能性切面。它不是“安全”的同义词，而是一个更大的容器，包含三个主要组件。这里先分清一个容易混淆的地方：安全性既可以单独作为一项非功能性要求，也是完整性的组成成分；两种说法说的是不同范围，并不矛盾。

组件	英文	大白话定义	一旦被破坏的灾难
数据完整性	Data Integrity	系统所使用和所维护的数据是完整（Complete）、正确（Correct）、无矛盾（Free of Contradictions）的	账户余额与真实余额不一致；同一笔转账在不同记录里得到两个互相矛盾的结果
行为完整性	Behavioral Integrity	系统按预期运行（Behaves as Intended），且没有逻辑错误（Free of Logical Errors）	点了“发送”却发出去两条；后退一步发现流程死循环；软件做出完全不合逻辑的举动
安全性	Security	系统把数据和功能的访问权限，限制在授权用户（Authorized User）范围内的能力	陌生人打开了你的私人相册；不改密码就能进后台

缺了任何一块会怎样：

只有安全性、没有数据完整性 → 门都锁着，但屋子里的东西本来就是错的。系统很“安全”地保管着一堆垃圾。
只有数据完整性、没有安全性 → 账本一分不差，但谁都能翻。准确却毫无价值，因为准确本身被人白看了。
有数据完整性 + 安全性、没有行为完整性 → 数据没错、外人进不来，但程序自己会做出莫名其妙的行为。你的保险箱很结实，但它会自己随机决定什么时候打开。

为什么我们对完整性毫无感觉？

因为它平时是“沉默”的。你每天用的那些 App 之所以没让你砸手机，背后是许多工程师在反复处理同时操作、意外情况和访问权限这些麻烦事。就像家里的电线：通电正常时它不存在于你的意识里，只有跳闸那一刻你才想起它。成功的技术有个副作用——它把自己隐藏起来了，于是它的价值也被一起隐藏了。

什么时候你会突然意识到它的价格？ 只有当它被打破的那一刻：

你写了一半的文档没保存就崩了 → 数据完整性破了
App 点了“提交”却跳到首页，什么都没发生 → 行为完整性破了
你的相册、聊天记录被陌生人看到 → 安全性破了

这也是为什么“完整性”是这一课真正要留下的东西——它是一把钥匙：等到系统不再由一家独自掌控，而是交给许多彼此独立的参与者共同维护时，谁来保证数据没有被随意改动？谁来保证所有人看到的是同一个版本？这时，“如何达成并维持完整性”就会从工程细节变成系统必须正面回答的问题。

3.7 这套坐标如何为后面的内容铺路

有了“两把刀 + 四个格子”，之后讨论任何复杂系统（包括区块链）时，你都可以问三个标准问题：

这个要素在哪一层？是用户的需求，还是达成需求的技术手段？
这个要素属于哪一面？是它“做不做得到”，还是它“做得好不好”？
如果它落在右下的“实现层 × 非功能性”格子里，它是不是在管完整性？具体是数据完整性、行为完整性，还是安全性？

这三个问题就是后续所有讨论的通用坐标系。没有它，关于“区块链到底解决了什么问题”的争论会退化成各说各话——就像开头那两个人，一个在讲信号，一个在讲微信。

拿一个具体场景练一次手。 假设你在评估“要不要给公司上一套考勤系统”，厂商讲了半小时，你只用三个问题就能把话拆开：

厂商的说法	哪一层	哪一面	该怎么追问
“支持人脸识别打卡”	应用层	功能性	这是我想要的吗？指纹行不行？
“打卡响应很快”	应用层	非功能性	大量用户同时打卡时还能保持快速吗？
“云端分布式存储考勤记录”	实现层	功能性	手段而已，别被技术名词唬住
“数据不会被管理员篡改”	实现层	非功能性	这才是重点——具体怎么保证的？谁来监督？

规律很明显：厂商容易讲前两行（用户听得懂、好演示），而最后一行更需要在设计和验收时继续追问。你现在已经具备了“把话钉回格子里”的能力。

4. 图解

图 1-1-1：两把刀切出一个系统

图 1-1-2：可见性梯度与“理所当然陷阱”

图 1-1-3：完整性三要素的逻辑与关系

图 1-1-4：从用户感受倒查到格子（灾难归因流）

5. 速记要点

不切分就不能思考，乱切分就不能沟通。 一切技术讨论的第一步是先统一坐标系，不是先争对错。
两把刀：横切“应用层 vs 实现层”（目的 vs 手段），竖切“功能性 vs 非功能性”（做什么 vs 做得怎样）。 两条轴彼此独立，可同时使用，得到 2×2 四格矩阵。
动词/副词记忆法：功能性是动词，非功能性是副词。 走得快、走得慢，“走”是同一个动作，变的只是方式。
可见性梯度：左上最显眼，右下最容易被当作理所当然。 用户学的是“应用层 × 功能性”；“实现层 × 非功能性”平时很少被注意，出问题时才被集中追问。
“看不见” ≠ “非功能性”。 压缩写盘是实现层的功能性（动作），别把它和实现层的非功能性（品质）混成一格。
完整性包含数据完整性、行为完整性和安全性三个主要组件。 三者分别关注数据是否正确一致、行为是否符合预期、访问是否受控。

6. 课后检测

C 里的“可用性高、响应速度快”虽然也是非功能性切面（这一点很容易迷惑人），但它不是完整性的构成组件。它和完整性是“同一大类下的不同项”，而不是“完整性的子项”。
关键区分：快 ≠ 对。系统可以响应极快但账本数据自相矛盾；也可以极慢但完整性无懈可击。所以性能与完整性互不包含。
这正是“实现层 × 非功能性”这一格内容很丰富（省电、省空间、隐私、性能、完整性并列）、但不能把整格都叫完整性的原因。

二、多选题（6–7）

题目 6

以下哪些属于非功能性切面（Non-Functional Aspect）？（选所有正确项）

A. 通过网络发送数据 B. 软件运行速度快 C. 用户数据保持私密与安全 D. 拍照 E. 以节省空间的方式存储数据

查看答案

答案：B、C、E

推导： 逐项用“动词/副词”测一遍：

A「通过网络发送数据」——这是一个动作，是动词，属于功能性切面。
B「软件运行速度快」——快是修饰“运行”这个动作的副词。
C「用户数据保持私密与安全」——描述的是数据处理方式应满足的约束，不是动作本身。
D「拍照」——纯动作，动词，功能性。
E「以节省空间的方式存储数据」——注意句式里的“以……的方式”，这是副词结构的标志，描述存储做得怎样。
混淆点提示：A 和 D 都容易被误选，因为它们是“听起来很重要”的功能。但重要与否不决定它是功能性还是非功能性，只看它是“做什么”还是“做得怎样”。

题目 7

关于“应用层与实现层”的划分，下列描述正确的有：

A. 应用层的要素可以用用户的日常词汇描述，不需要技术背景 B. 实现层的要素本质上是技术性的 C. 实现层的要素自身就是目的，与技术目标无关 D. 实现层的要素是“手段（Means to an End）”，其存在意义在于服务上层需求 E. 一条要素落在哪一层，取决于开发它的团队规模

查看答案

答案：A、B、D

推导：

A 应用层用用户日常词汇即可描述：听音乐、拍照、订酒店房间。
B 实现层要素在本质上是技术性的（数字信息转声学信号、识别像素颜色、通过互联网发送报文）。
C 说反了。实现层要素是手段（Means to an End），即“为了达成别的东西”，它自身不是目的。声称技术细节“自身就是目的”，会把讨论拖回“我实现得很精巧所以不能说它没用”的无效争论。
D 正确表述了“手段”属性。
E 团队规模是组织结构变量，不是系统本身的属性；这正是按开发分工切系统不可靠的典型例子。

三、判断题（8–9）

题目 8

判断正误：因为“连接最近的移动通信接入点”是普通用户完全看不见的技术细节，所以它属于非功能性切面。

查看答案

答案：错误

推导： 两把刀必须各归各的轴，不许串门。

“连接最近的移动通信接入点”是一个动作——它做的是“某件具体的事”，所以它是功能性切面。
它同时是技术内部的、用户看不见的——所以它落在实现层。
合并定位：实现层 × 功能性，而不是非功能性。
误区根源：题目把“看不见”当成“非功能性”的判据。实际上“看不见”只影响可见性（那是“实现层”带来的结果），完全不改变“它是动作还是动作的品质”这一判定。这题与第 1 题的 D 选项、第 4 题的陷阱，构成同一个易错点的三重验证。

题目 9

判断正误：一个系统只要做好了安全性（Security），就已经具备了完整性（Integrity）。

查看答案

答案：错误

推导： 完整性包含数据完整性、行为完整性和安全性三个主要组件。本题不能只凭安全性就认为完整性已经满足，还要分别检查数据完整性和行为完整性。

只做好安全性，可能出现：门全锁着、外人进不来，但库里的数据本身自相矛盾（数据完整性缺失），或者程序自己跑出不合逻辑的行为（行为完整性缺失）。
结果是“一个很安全地保管着错误数据的系统”——它在工程上仍然是彻底失败的。
常见混淆：把“安全”当成“完整”的近义词。事实上安全性只是完整性的一个子组件。口语里的“数据安全”常常混用两个概念，判定时要抓定义：安全性谈的是谁能访问，数据完整性谈的是数据对不对。

四、深度情景分析大题（10）

题目 10

情景：你是一家在线票务平台的运维负责人。某日凌晨，用户集中投诉三件事：

投诉一：一部分用户的订单页显示“已成功购票”，但检票系统里查不到这张票；另有多名用户发现同一张座位被两个人同时买下。
投诉二：有用户反馈，点击“申请退票”后，系统既不报错也不成功，页面一直停在原地，重新登录后订单直接变成“已作废”，谁都不知道是谁操作的。
投诉三：一位外部网友发帖称，他无需登录、只把订单号里的数字往后递增几位，就能看到大量他人的完整姓名、手机号和身份证末几位。

复盘会上，产品负责人拍板：“这是数据库性能问题，先扩容，把响应压下去。”

请你回答：

（a）把三条投诉分别定位到完整性（Integrity）的哪个组件？说明你的判断依据。（b）用“两把刀”矩阵，指出这三条投诉共同的落点格子，并解释为什么用户和产品负责人都很难准确说出问题的位置。（c）产品负责人的“扩容”决定，能否解决其中任何一条投诉？请逐条论证，并指出这个判断错误背后的思维误区。

查看答案

（a）三条投诉的完整性组件定位

投诉	表现	归因	依据
投诉一：页面显示“已成功购票”但检票系统查不到；同一座位被两人买下	同一份业务事实在不同位置给出了不一致、甚至互相冲突的答案	数据完整性（Data Integrity）	数据完整性的定义正是"数据完整、正确、无矛盾"。"票存在但两边对不上“直接违反”无矛盾"；"同一座位卖出两次"是最典型的自相矛盾。注意：每条记录单独看可能都没写错，错的是记录之间互相打架。
投诉二：点退票既不报错也不成功；重新登录后订单变“已作废”，无人知道操作者	系统没有按预期运行，订单进入了一个无法解释的状态	行为完整性（Behavioral Integrity）	定义是“系统按预期运行，且没有逻辑错误”。“不报错也不成功”说明流程走到一半没有明确结果；“订单莫名其妙作废”说明系统做了用户没有预期到的动作。这里数据本身可能已经写着“已作废”，但它是由错误行为造成的，所以问题出在行为。
投诉三：不登录、把订单号数字递增就能看到他人姓名、手机号、证件号	未授权者获得了对数据和功能的访问	安全性（Security）	定义是“把数据和功能的访问权限，只限制在授权用户（Authorized User）范围内”。平台把一个可以猜到的订单号当成了通行证，没有核实访问者是谁、是否有权查看。这是访问权限问题，与数据对不对、行为合不合逻辑都无关。

（b）矩阵落点，以及为什么双方都说不准位置

三条投诉的落点完全一致：实现层 × 非功能性这一格，并且这一格里最核心的那项——完整性（Integrity）——被全部命中（数据、行为、安全三块各破一角）。

为什么用户说不准：

用户能直接看见的只有应用层 × 功能性（“我要买到票”“我要退票”）。他们的表达必然停在这一层：“我买不到票”“我的票没了”。
而真正的破损点在实现层非功能性——用户在这条可见性梯度上根本看不见病因，只能看见症状。

为什么产品负责人也说不准：

他把三条现象全部压缩成一句“数据库性能问题”。这是用“快不快”这个非功能性维度，去覆盖“对不对/谁能访问”这些完全不同性质的维度。
深层原因是他把**“实现层”和“非功能性”混成了同一个筐**：既然都在“用户看不见的地方”，就一并当作“底层性能”来处理。而按两把刀体系，性能、完整性等是实现层非功能性格子里并列的不同项，彼此不能互相替代（第 5 题的区分正是这里的钥匙）。
至于投诉三，他甚至完全没往“谁能看、谁不能看”这个方向看一眼——因为安全性同样藏在那个不可见的格子里。

（c）扩容能否解决？逐条论证

投诉一（数据完整性）：不能解决。 扩容改善的是系统能同时处理多少请求、响应有多快。但这里的问题是：同一张票在不同地方留下了互相矛盾的记录，而且系统没有拦住同一个座位被重复卖出。两个购买请求几乎同时到达时，系统没有让它们排队，也没有确认谁先成功，结果两边都以为自己是唯一成功者。这些都不是速度快慢能修复的。
投诉二（行为完整性）：不能解决。 退票流程在“提交”和“完成”之间留下了没有处理的情况：既不明确成功，也不明确失败，订单却变成了“已作废”。页面变快不会补上这段流程逻辑。若问题原本由等待太久、操作被中断引发，减少同时访问的人数可能降低复发频率，但根因仍在，只是被暂时掩盖。
投诉三（安全性）：不但不能解决，扩容还可能加重它。 越权访问的根源，是把一个可以猜到的订单号当成了通行证，没有核实“你是谁、能不能看”。扩容不会改变这一点。若为了扩容增加更多对外入口，每个入口都要单独检查身份和权限；漏掉一处，泄露面反而扩大。
结论： 扩容对三条投诉一条都无解。真正需要做的是：让同一张票在各处保持一致并阻止重复售卖；补齐退票流程的成功、失败和异常分支；给每次访问加上身份和权限检查。三件事都落在同一个格子里，但都不是性能问题。

背后的思维误区（最值得带走的三点）：

跨格串门：把发生在同一格子里的三种不同问题（数据对不对、行为对不对、谁能访问）笼统合并成“底层的问题”，再合并成“性能问题”。两把刀体系的全部价值，就在于阻止这种合并。
“理所当然”陷阱的后果外溢：由于日常里右下格总是成立，团队就默认它不需要专门设计与专门验收，于是出问题时无从归因，只能凭直觉抓一个最熟的指标（响应时间）。
只看容易验收的东西：动词（“能购票”）容易写进需求文档、容易验收；副词（“数据要无矛盾、行为要可预期、访问要受控”）容易被省略。这些投诉提醒我们，应在立项时把这些非功能性要求正式定义出来。

因此本课的实操价值不在于分类本身，而在于：在立项时就把右下格逐项写进需求，并指派责任人。