上一篇讲"这是哪种文档"。这一篇讲最小单位：一句话读不懂，怎么办。
绝大多数人的第一反应是查单词，但九成情况下，问题不在词，在结构。
一、先诊断：你属于哪一种"读不懂"
同一个现象，三种不同的病因。治错了，白费劲。
| 症状 | 真实病因 | 该做什么 |
|---|---|---|
| 每个词都认识，连起来不知道在说啥 | 句子结构 | 找主干 |
| 有几个词不认识，卡住了 | 词汇 | 查，但只查那几个 |
| 词认识、结构也懂，但不知道作者什么意思 | 背景知识 | 查概念，不是查语言 |
先花五秒判断是哪一种。 大部分人是第一种，却一直在做第二种的事。
二、技术英语的句子为什么难
不是因为"长"。中文也有很长的句子。
真正的三个原因：
1. 修饰语后置
中文说"被浏览器缓存的响应"，英语说 the response **cached by the browser**。
英语把定语放在后面，还用从句一层层套。 这是结构差异，不是难度差异。
2. 插入成分可以无限嵌套
The function, which is called only when the cache is empty
(that is, on the first request after a restart), returns null.
一个句子插了两层括号。中文很少这样写，但英语技术文档天天这样写。
3. 名词化堆叠
user authentication token refresh failure handling logic
五个名词连在一起，没有一个介词。这在中文里几乎不可能，在英语技术写作里是常态。
这种结构的解法和从句完全不一样——要从后往前拆。
三、方法一：砍掉所有"可以拿掉"的部分
技术英语的句子，通常有 40% 是可以整块删掉而不影响主干的。
先删这几类：
| 类型 | 标记 | 例 |
|---|---|---|
| 括号内容 | (...) | 补充说明，删掉不影响主句 |
| 破折号内容 | — ... — | 同上 |
| 逗号包起来的从句 | , which ... / , that is ... | 非限定，删掉 |
| 介词短语 | in order to / by means of / with respect to | 常是废话 |
| 举例 | e.g. / such as / including / i.e. | 删掉 |
实战：一句真实的文档
In cases where the underlying storage engine, which may be backed
by either a local filesystem or a remote object store (see the
configuration section for details), fails to respond within the
configured timeout, the request is rejected with a 503 status.
看着很吓人。按上面的规则砍：
- 删括号
(see the configuration section for details) - 删逗号从句
, which may be backed by either a local filesystem or a remote object store - 删
In cases where→ 换成If
剩下：
If the underlying storage engine fails to respond within the
configured timeout, the request is rejected with a 503 status.
一句话：存储引擎超时没响应，请求返回 503。
从 55 个词到 22 个词，意思一点没丢。
四、方法二：找主干，只找主谓宾
砍完之后如果还乱，用这个更硬的办法：只找三样东西。
1. 谁是主语（谁）
2. 动词是什么（干吗）
3. 宾语是什么（对谁）
其他全部暂时标成"不重要"，等主干清楚了再回头看。
实战
The client library will, upon successful negotiation of the
protocol version with the server, begin transmitting queued
messages using the selected compression algorithm.
找主干：
- 主语：
The client library - 动词：
will begin transmitting（will和begin中间插了一大段，这是最难的地方） - 宾语：
queued messages
主干：客户端库开始发送排队消息。
其余信息再挂回去：
upon successful negotiation of the protocol version with the server—— 什么条件下using the selected compression algorithm—— 用什么方式
最容易骗人的结构
助动词和主动词被隔开，这是技术英语的经典陷阱：
The system shall, unless explicitly configured otherwise,
reject all requests.
shall 和 reject 隔了一整句。第一遍读容易看漏 reject，以为是个肯定句。
看到 shall / will / must / can 之后，一定要往后找到真正的动词。
五、方法三：名词串从后往前拆
专门对付 user authentication token refresh failure handling logic 这种。
规则：最后一个词是中心词，前面全是修饰。
user authentication token refresh failure handling logic
↑ 中心词
从后往前剥：
| 层 | 结果 |
|---|---|
| 1 | logic —— 一套逻辑 |
| 2 | handling logic —— 处理逻辑 |
| 3 | failure handling logic —— 失败处理逻辑 |
| 4 | refresh failure handling logic —— 刷新失败处理逻辑 |
| 5 | token refresh failure... —— 令牌刷新失败处理逻辑 |
| 6 | authentication token refresh... —— 认证令牌刷新失败处理逻辑 |
| 7 | user authentication token... —— 用户认证令牌刷新失败处理逻辑 |
从后往前读，一层层套上去。 反过来（从前读）永远读不通。
一个判断技巧：如果连续三个以上名词堆在一起，最后一个一定是中心词，前面全是它的定语。
六、方法四：长定语拆成短句
英语喜欢把定语从句塞在名词后面，中文习惯拆开说。
遇到 which / that / who 引导的从句，先把它拿出来，单独翻译，再放回去。
实战
This parameter controls the maximum number of connections that
the pool will keep open, which are closed after being idle for
the configured idle timeout.
拆：
- 主句：
This parameter controls the maximum number of connections—— 这个参数控制最大连接数 - 从句 1：
that the pool will keep open—— 连接池保持打开的 - 从句 2：
which are closed after being idle for the configured idle timeout—— 空闲超时后被关闭
合：
这个参数控制连接池保持打开的最大连接数；这些连接在空闲超过配置的超时时间后会被关闭。
拆的时候注意 which 指谁——这里指 connections，不是指 number。英语的指代经常模糊，要靠语义判断。
七、方法五：被动语态先还原成主动
技术文档里被动语态极多，因为它"客观"。但中文读起来绕。
读不懂时，先问：谁做的？
The request is validated before being forwarded to the backend.
被动的。还原：
系统在把请求转给后端之前，先校验它。
注意 before being forwarded 这种结构——being + 过去分词 表示"在被……的时候"，中文里没有对应结构，直译会很别扭。直接换成"在……之前"。
什么时候被动语态是真信息
有时候作者用被动是故意的——因为做这件事的人不重要，或者不想说。
The configuration file has been modified.
没说谁改的。这可能意味着"不知道谁改的"，也可能意味着"别问谁改的"。
在故障报告、安全公告里，被动语态的"施动者缺失"往往是重点。
八、方法六：先读最后一句
这一条很反直觉，但极其管用。
英语技术文档的段落，结论经常在最后一句。
原因：英文学术写作的段落结构是"先铺垫，后结论"（这和中式写作的"先给结论再解释"正好相反）。
所以读不懂一段时，先看最后一句。
HTTP/2 introduces multiplexing, which allows multiple requests
to share a single connection. This reduces latency by avoiding
head-of-line blocking at the TCP level. However, this benefit
depends on the underlying transport. In practice, if the network
has high packet loss, the advantage largely disappears.
直接看最后一句：丢包严重时，优势基本消失。
前面三句全是在为这一句做铺垫。
九、一个完整的工作流
遇到读不懂的句子，按这个顺序走，每步只花几秒：
1. 先砍
→ 删括号、删破折号、删逗号从句、删举例
→ 还剩看不懂？下一步
2. 找主谓宾
→ 只找"谁 + 干吗 + 对谁"
→ 注意助动词和主动词可能被隔开
3. 名词串倒着拆
→ 三个以上名词连在一起时，最后一个才是中心词
4. 从句拿出来单算
→ which / that / who 引导的，先摘出来翻译，再放回去
5. 还是没有？
→ 直接查背景概念，不要继续查单词
关键在于顺序：先结构，后词汇，最后概念。反了就是白费劲。
十、三句实话
第一，读不懂的时候，多半不是词的问题。 技术文档的词汇量其实很小。你查了十个词还读不懂，说明问题在结构。
第二，翻译腔是读不懂的根源之一。 很多人习惯在脑子里逐词翻译成中文，再理解中文。这条路永远绕远。 正确做法是：把英语句子砍成短块，每块直接理解，不经过中文。
第三，练这件事最快的办法是"改文档"。 看到一句特别绕的官方文档，自己把它改写成三句短的。写不出来说明你真没懂；写出来了，这句话你一辈子不会忘。
这是我的个人整理。文中所有例句都是按真实技术文档的常见句式构造的，不是任何具体文档的原文。
这个系列的其他几篇
- GitHub 是最好的英语老师：从读 Issue 到能开口 —— 从哪儿练
- 技术文档有四种，读法完全不同 —— 读之前先认类型
- 在 PR 里把话说清楚：一来一回的完整样本 —— 怎么写
- 技术人的口语：不追求流利，追求说对 —— 怎么说
- 计算机英语高频术语对照表 —— 随时查