装完 Proxmox VE 7兴冲冲打开 shell 敲下apt-get update回车之后滚出来一屏红色的E:最后一行是E: ... failed: exit code 100这个场景我遇到过不止一次。Proxmox VE 7 基于 Debian 11代号 bullseye它的软件源结构和普通 Debian 不太一样官方镜像装完之后默认挂着一个需要商业订阅才能访问的企业源再加上 GPG 密钥、系统时间、DNS 解析、磁盘空间这几处容易出问题的环节一个新装好的节点在第一次更新时失败其实相当常见。exit code 100本身不是一个具体故障而是 apt 这一类工具在“操作没能完成”时给出的兜底退出码它把真正的原因藏在上面几行输出里。这篇文章面向所有正在用 Proxmox VE 7 做虚拟化实验、跑家庭实验室或者维护小型集群的朋友不管你是第一次接触 Debian 系包管理的新手还是已经能背出 apt 参数的老手我把自己排查这类问题的完整思路、每一步的命令和判断依据以及几个只有实际遇到过才会记住的细节全部整理在这里你可以直接照着复现和抄作业。1. 先搞懂 exit code 100 到底在说什么1.1 apt 退出码的语义与被淹没的真相很多人看到exit code 100的第一反应是去搜这个数字但说实话这个数字提供的信息量几乎为零。在 apt-get 的约定里0 表示一切顺利100 表示“操作失败存在错误”101 才是“找不到指定的包”。也就是说100 是一个笼统的失败标记它既可能是网络不通也可能是源地址写错还可能是签名验证没过甚至可能是磁盘写满了导致临时文件创建失败。真正有价值的信息永远在它上面那几行尤其是带E:Error、W:Warning、N:Notice前缀的句子。我习惯的做法是先不急着看最后一行而是把整个输出从头往下扫一遍重点抓三个东西第一有没有Failed to fetch有的话后面跟的 URL 就是嫌疑源第二有没有401 Unauthorized、403 Forbidden、404 Not Found这类 HTTP 状态码这直接指向权限或路径问题第三有没有NO_PUBKEY、does not have a Release file、signatures couldnt be verified这类签名相关的句子。这三类信息基本能覆盖九成以上的场景。提示如果你是在网页控制台noVNC 或 xterm.js里操作的输出可能被截断滚动条往上拉不一定能看到完整的错误。建议直接用 SSH 连上去或者在命令后面加21 | tee /tmp/apt-update.log把完整输出落到文件里慢慢看。还有一个容易被忽略的点exit code 100有时并不是唯一的错误输出里可能同时存在三四条E:。比如企业源 401 和 Debian 源解析失败同时发生这种情况下你修好一个另一个还在重新执行又报 100会让人误以为“改了没用”。所以我的原则是一次只改一处改完重新跑看报错条数有没有减少用“错误条数递减”来判断进度而不是用“有没有完全成功”来判断。1.2 三类根因把问题切成三块以我的经验Proxmox VE 7 上apt-get update报 100根因基本落在三个层面而且这三层的排查顺序是有讲究的。第一层是源配置层也就是/etc/apt/sources.list和/etc/apt/sources.list.d/下面那些文件写的内容对不对。Proxmox VE 7 官方 ISO 安装完成后/etc/apt/sources.list.d/pve-enterprise.list里默认有一条指向企业仓库的记录没有订阅授权的情况下访问它会返回 401这是新装节点最典型的失败原因。同样地旧版本残留的 Ceph 源、写错代号比如把 bullseye 写成 buster的条目都会在这一层出事。第二层是网络与解析层包括 DNS 能不能解析出镜像域名、IPv6 有没有被错误优先、防火墙或代理有没有拦截、镜像站本身是否可达。这一层的特征是报错里出现Temporary failure resolving、Connection timed out、Could not connect之类的字眼。第三层是环境与状态层包括 GPG 公钥是否导入、系统时间是否准确、根分区剩余空间是否够用、有没有其他 apt 或 dpkg 进程占着锁。这一层最阴险因为报错文本往往和真实原因隔了一层比如时间漂移导致签名校验失败报的却是NO_PUBKEY容易把人带偏。把问题切成这三块之后排查就变成了一个排除法流程先用几条命令确认网络通不通再看源文件写得对不对最后检查密钥、时间和空间。顺序反了也不算错但先做前两步能省下大量时间毕竟网络不通的时候你去折腾 GPG 密钥纯属白费力气。1.3 三条命令把排查范围缩到最小我通常会在正式动手之前跑三条命令几十秒内就能把范围缩小一大半。第一条是看源清单grep -r . /etc/apt/sources.list /etc/apt/sources.list.d/把当前生效的所有源配置一次性列出来。这条命令的好处是不会漏掉sources.list.d目录下的碎片文件很多人只改了主文件忘了子目录里还躺着一个企业源。第二条是测解析getent hosts download.proxmox.com或者ping -c 2 download.proxmox.com。前者比 ping 更干净因为它只查解析不发包能区分“解析失败”和“解析成功但连不上”这两种完全不同的情况。第三条是测连通curl -I -m 10 http://download.proxmox.com/debian/pve/dists/bullseye/Release直接看 HTTP 响应头。如果返回 200说明网络路径和源地址都没问题锅在本地配置如果返回超时锅在网络如果返回 404说明地址或代号写错了。# 一次性把源配置、解析、连通性都看一遍 grep -rn . /etc/apt/sources.list /etc/apt/sources.list.d/ 2/dev/null getent hosts download.proxmox.com curl -I -m 10 -s http://download.proxmox.com/debian/pve/dists/bullseye/Release | head -n 5这三条跑完你基本就知道该往哪一层深挖了。我特别推荐第三条因为它是唯一能直接验证“这台机器能不能取到那个文件”的手段比反复跑apt-get update看红字高效得多。1.4 一个容易被误判的细节exit code 与输出顺序还有个小细节值得单独说apt 的输出顺序不代表错误发生的顺序。apt 会先并行去拉取多个源的索引然后统一汇总报错所以你看到的E:行可能是最后才打印的但错误本身是最早发生的。这就解释了为什么有时候你把第一条报错修好了第二条报错的内容会“变”成之前那条——其实它一直都在只是被前面那条挡住了。另外apt-get update结尾报 100 的场合前面往往夹着几条W:警告。警告本身不会导致 100但它的内容经常是根因的线索。举个实际例子W: GPG error: ... The following signatures couldnt be verified because the public key is not available这条只是警告但紧接着就会出现E: The repository ... is not signed然后 exit 100。这时候你盯着E:看是找不到解的得回头看W:里那个被截断的公钥 ID。2. 企业源与订阅源Proxmox 7 最常见的那颗雷2.1 为什么会冒出 401 UnauthorizedProxmox VE 7 用官方 ISO 装完之后/etc/apt/sources.list.d/pve-enterprise.list里会有一条类似这样的记录deb https://enterprise.proxmox.com/debian/pve bullseye pve-enterprise这个仓库是给付费订阅用户准备的服务端会检查请求里带的认证凭据。没订阅的机器去访问服务端直接回 401apt 拿不到Release文件就会报E: Failed to fetch https://enterprise.proxmox.com/debian/pve/dists/bullseye/InRelease 401 Unauthorized并且最终以 100 退出。这里有个容易被误解的地方很多人以为“401 是密码错了”然后去找什么账号密码配置。其实 Proxmox 的订阅认证是通过单独的凭据文件走的普通用户根本没必要去碰正确做法是把企业源拿掉或者注释掉换成免费的 no-subscription 仓库。这不是“破解”而是官方明确支持的免费使用方式——企业源本来就是为订阅用户提供稳定更新通道的免费用户走公共仓库完全合规。2.2 切换到 no-subscription 源的完整操作我一般分四步走顺序不能乱否则容易在中间状态里踩坑。第一步先备份现有配置出问题能一键回滚mkdir -p /root/apt-backup cp -a /etc/apt/sources.list /root/apt-backup/ cp -a /etc/apt/sources.list.d /root/apt-backup/第二步处理企业源。我倾向于注释而不是直接删除因为注释保留了原始内容将来万一买了订阅把#去掉就能用不用凭记忆重建sed -i s|^deb |#deb | /etc/apt/sources.list.d/pve-enterprise.list执行完用cat确认一下应该看到整行前面多了#。如果这个文件里有多行sed会全部处理一般没问题。第三步添加免费仓库。这里要注意 Proxmox VE 7 对应的代号是 bullseye写错代号是最常见的低级错误echo deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription \ /etc/apt/sources.list.d/pve-no-subscription.list第四步导入仓库签名公钥。Proxmox 从 7.x 开始用独立的 release key公钥没导入的话会报NO_PUBKEYwget https://enterprise.proxmox.com/debian/proxmox-release-bullseye.gpg \ -O /etc/apt/trusted.gpg.d/proxmox-release-bullseye.gpg注意这里用的是trusted.gpg.d目录加.gpg后缀的写法这是较新的推荐方式比apt-key add更规范apt-key在新版本里已经被标记为废弃。公钥文件下载完可以用gpg --show-keys看一眼内容确认不是下载到了一个 404 页面。做完这四步再跑apt-get update企业源的那条 401 应该消失。如果还剩其他报错那就是别的原因继续往下看。2.3 源文件写法的细节与那些年踩过的笔误源配置这一行看着简单但写错的方式千奇百怪我把自己见过和踩过的列一下你对号入座能省不少时间。现象原因修法404 Not Found代号写错如把 bullseye 写成 buster确认系统版本后改正代号404 Not Found仓库路径多了或少了/debian/pve对照官方文档核对完整 URL401 Unauthorized还在用企业源注释企业源换 no-subscriptionRelease file 不存在行内组件名写错如pve-enterprise用在免费源上组件名改为pve-no-subscription语法错误Malformed entry行内多了空格、少了字段或用了中文标点逐字符核对注意别把全角空格粘进去最后一条尤其坑人。从网页上复制源配置的时候很容易连带粘进全角空格或者不可见字符apt解析时报Malformed entry 1 in list file一眼看过去那行“明明长得一样”。判断办法是用cat -A看行尾正常应该以$结束如果出现M-BM-之类的东西就是混进了特殊字符。我现在的习惯是宁可手敲一遍也不从浏览器复制。还有个顺序问题sources.list和sources.list.d里的文件是合并生效的同名的组件出现在多个文件里不会报错但重复拉取会拖慢速度。整理完源之后建议用apt-cache policy看一眼每个包的候选来源如果同一个包有两个不同版本的候选说明源配重了该清理一下。2.4 Ceph 源另一个常见的 401 来源Proxmox VE 7 早期版本在sources.list.d里还会放一个ceph.list指向 Ceph 的仓库。不跑超融合存储的机器根本用不上这个源但它同样需要订阅认证访问时一样会给 401。新版 ISO 已经把这一行默认注释掉了但从旧版本升级上来的机器大概率还留着。处理方式和前面一样注释掉即可。判断是否需要保留的标准很简单如果你不打算在这台机器上部署 Ceph 集群那这个源就是纯粹的干扰项。我见过有人的节点每次apt-get update都要等十几秒超时其实就是这个源在拖时间——它不影响功能但影响体验顺手清掉更好。3. 密钥、签名与时间看不见的验证链条3.1 NO_PUBKEY 与 Release 文件缺签名的处理apt 的签名验证机制是这样的每个仓库的Release文件都带 GPG 签名apt 拿到文件后要用对应的公钥去验。公钥不在本地钥匙串里就报NO_PUBKEY紧接着因为验证失败整个仓库被视为不可信报The repository ... is not signed最后 exit 100。处理这个的标准动作是把公钥导进来。前面已经给了 Proxmox 官方 key 的写法这里补充一下通用的三种方式因为不同的源对应不同的 key 来源。第一种是官方提供的 key 文件直接下载放到/etc/apt/trusted.gpg.d/文件名后缀用.gpg或.asc都行apt 会自己识别。第二种是从 keyserver 拉gpg --recv-keys配合--keyserver参数但这条路径依赖 keyserver 的可达性国内网络环境下有时会卡住我一般不用。第三种是从已有的 keyring 里导出适合内网镜像站自签名的情况。有一个细节值得提醒公钥文件的权限。放在trusted.gpg.d里的文件属主应该是 root权限 644 就够。如果权限过宽较新版本的 apt 会直接拒绝加载报错的措辞还很不直观。改完权限用apt-get update试一次如果NO_PUBKEY还在用apt-key list或者gpg --list-keys --keyring /etc/apt/trusted.gpg.d/xxx.gpg确认公钥真的进去了。注意不要用apt-get update --allow-insecure-repositories这类参数去“绕过”签名验证。绕过之后 apt 确实不报 100 了但你装上的包就没有完整性保护这是实打实的安全风险。签名验证失败的根因是密钥缺失或时间不对把根因解决掉才是正路。3.2 系统时间漂移导致的签名失效这一类问题最难查因为报错文本和真实原因完全对不上。GPG 签名验证会检查签名的时间戳如果系统时间比签名时间还早或者和真实时间偏差太大验证就会失败而 apt 报出来的往往还是NO_PUBKEY或者signatures were invalid。为什么会时间不准虚拟化环境里太常见了。刚装好的虚拟机时钟可能还停在 ISO 的构建日期NTP 服务没起来或者宿主机本身的时间就不对通过 RTC 传给了虚拟机。还有一种情况是虚拟机被长时间挂起后恢复时钟直接停住。检查一条命令就够timedatectl。看System clock synchronized是不是yes看NTP service是不是active。如果没同步开一下timedatectl set-ntp true systemctl restart systemd-timesyncd sleep 5 timedatectl status同步完成之后再跑apt-get update很多时候签名报错会自己消失。我印象最深的一次一台测试机折腾了快一个小时源文件改了又改密钥导了三遍最后发现是这台机器从快照恢复之后时间停在了三个月前date一看就恍然大悟。从那之后我排查签名问题都是先看时间一秒的检查省下的是几十分钟。3.3 证书过期这类隐蔽的报错企业源走的是 HTTPS如果本地 CA 证书库过期或者系统时间不对导致证书“还没生效”或“已经过期”TLS 握手阶段就会失败报错形如Certificate verification failed或者server certificate verification failed。这类报错看起来很像网络问题实际上是信任链的问题。处理思路是先确认时间上一节已经说了再确认ca-certificates包是不是完整dpkg -l ca-certificates | grep ^ii update-ca-certificates --fresh第二条命令会把/etc/ssl/certs重新生成一遍如果有证书缺失或者损坏这一步能修好大部分情况。还有一类不太常见但确实存在的情况内网做了 TLS 拦截中间设备用自签证书替换了原始证书apt 自然验不过。这种环境下正确做法是把内网 CA 的公钥放到/usr/local/share/ca-certificates/下后缀用.crt然后跑update-ca-certificates而不是去关掉验证。关掉验证Acquire::https::Verify-Peer false相当于把安全门槛拆了只在完全隔离的实验环境里作为临时手段考虑绝不能留在生产机上。4. 网络与 DNS报错不在 apt 身上的那一半4.1 解析失败、IPv6 优先与镜像可达性Temporary failure resolving download.proxmox.com这条报错非常直白就是 DNS 解析没成功。但背后的原因有好几种得分清楚。最常见的是/etc/resolv.conf里没有可用的 DNS 服务器或者指向了一个不可达的地址。新装的系统如果网络配置没走 DHCP这个文件可能是空的。检查方法就是cat /etc/resolv.conf看有没有nameserver行。第二种是 systemd-resolved 在中间捣乱。如果resolv.conf是个指向/run/systemd/resolve/stub-resolv.conf的软链接而 resolved 服务又没起来解析就会全部失败。用resolvectl status看每个网卡的 DNS 配置比直接看文件更靠谱。第三种是 IPv6 相关。很多镜像站有 AAAA 记录apt 默认会优先尝试 IPv6。如果这台机器有 IPv6 地址但没有实际的 IPv6 出口就会卡在连接超时上表现是apt-get update特别慢最后超时报 100。这种问题的特征是“IPv4 能通但 apt 就是不行”。我常用的验证和规避手段是强制走 IPv4apt-get -o Acquire::ForceIPv4true update如果加上这个参数就正常了那基本可以确定是 IPv6 路径有问题。长期的解决办法是在系统层面关掉 IPv6 或者调整优先级而不是每次敲命令都带参数。至于关掉 IPv6 的具体配置各家网络环境差异太大我这里只说思路先确认确实不需要 IPv6再动配置别为了绕过一个报错把网络能力砍掉。4.2 代理配置的正确位置与常见写错有些环境必须走代理才能出网这时候 apt 需要单独配置因为它读的不是 shell 的环境变量虽然部分版本会读但行为不稳定。正确的位置是/etc/apt/apt.conf.d/下新建一个文件比如99proxyAcquire::http::Proxy http://10.0.0.1:3128; Acquire::https::Proxy http://10.0.0.1:3128;写完用apt-config dump | grep -i proxy确认配置被读到了。这里最常见的错误是忘记分号apt 的配置文件语法要求每行以分号结尾少了分号整行会被忽略而且不报错你会以为配了其实没配。第二个常见错误是代理地址写成了域名但本机 DNS 还没通形成了死循环——解析不了代理域名自然也就用不了代理最后报的还是解析失败。还有一种情况是代理只支持 HTTP 不支持 HTTPS 的 CONNECT访问 https 源时会失败。这种时候要么把源换成 httpProxmox 的免费源本身支持 http要么让网络管理员放开 CONNECT 权限。我不建议在 apt 层面关闭证书验证来绕过原因前面已经说过了。4.3 本地缓存与磁盘空间这个原因容易被忽略但报错形态很有辨识度E: You dont have enough free space in /var/cache/apt/archives/。根分区满了之后apt 连索引文件都写不进去自然 exit 100。Proxmox VE 默认的根分区不算大如果在这台机器上跑了很多虚拟机的镜像文件、日志没清理、或者做过几次大版本升级/var很容易被撑满。一条df -h就能看出来。清理的思路按收益从高到低排先apt-get clean清掉下载的 deb 包再清/var/log下的旧日志用journalctl --vacuum-size200M比手删更安全最后考虑删掉不用的旧内核。说到旧内核Proxmox VE 升级内核之后会保留旧版本/boot分区容易被占满。检查df -h /boot如果快满了用dpkg -l | grep pve-kernel列出现有内核保留当前运行的版本和上一个版本其余用apt-get purge清掉。清理前务必确认uname -r输出的版本不要被误删删错了机器起不来那就从一个小问题变成大问题了。另外还有一个和缓存相关的小坑/var/lib/apt/lists/下的索引文件损坏时apt 会报Problem with MergeList之类的错误。这种情况不用深究原因直接清空重来rm -rf /var/lib/apt/lists/* apt-get update这条命令是无损的索引本来就是可以重新下载的缓存删掉不影响已安装的软件。4.4 进程锁与 dpkg 中断残留还有一类报错和网络、签名都没关系是环境状态问题。典型表现是E: Could not get lock /var/lib/dpkg/lock-frontend说明有另一个 apt 或 dpkg 进程在跑。可能是你之前开了一个终端在装包忘了关也可能是某次安装被强制中断留下了锁。处理方式是先确认进程ps aux | grep -E apt|dpkg。如果确实有活着的进程等它跑完或者正常终止它。如果没有进程但锁文件还在说明是残留可以删。但我要强调一点删除锁文件只在前一步确认没有活跃进程的前提下才安全否则相当于把并发保护拆了两个 apt 同时操作 dpkg 数据库很容易把系统搞坏。比锁更麻烦的是 dpkg 被中断后的半完成状态报错会出现dpkg was interrupted, you must manually run dpkg --configure -a。按提示跑就行dpkg --configure -a apt-get -f install第二条是修复依赖关系。这两条跑完之后再apt-get update通常就恢复正常了。我在虚拟机上做过粗测从强制断电恢复的系统里这套组合拳能解决八成以上的包管理异常。5. 常见问题速查表与避坑心得5.1 报错原文对照速查表排查的时候最怕的是不知道那句话在说什么。我把实际遇到过的报错原文和对应处理整理成表遇到问题先来这里对一眼比漫无目的地搜要快得多。报错关键词真实含义处理动作exit code 100通用失败不指向具体原因往上看第一条E:401 Unauthorized企业源需要订阅注释企业源切到免费源404 Not Found路径或代号写错核对 URL 和 bullseye 代号Temporary failure resolvingDNS 不通检查 resolv.conf 和 resolved 服务Connection timed out网络不可达或被拦测连通性考虑 IPv4 强制NO_PUBKEY公钥缺失导入对应 release keyis not signed签名验证失败先导公钥再查系统时间Release file expired索引文件过期校准时间后重试does not have a Release file该路径不是有效仓库检查仓库地址和组件名Could not get lock有进程占用确认进程后清理残留锁dpkg was interrupted上次操作中断dpkg --configure -aNo space left on device磁盘满清缓存、清日志、清旧内核Malformed entry源文件语法错误cat -A查不可见字符MergeList相关索引缓存损坏删/var/lib/apt/lists/*重下这张表里我最想强调的是第一行。很多人卡住就是因为盯着 100 这个数字找答案而它本身什么也没告诉你。养成“先看第一条 E 行”的习惯排查效率会立刻不一样。5.2 几个我实际踩过的坑坑一改了源文件但忘了 apt 会缓存失败结果。有一次我把企业源注释掉了重新跑apt-get update结果还是报 401我一度以为注释没生效反复cat文件确认。后来才反应过来是终端里的输出滚上去了我看到的红字是旧的那一屏。教训是改完配置之后先clear一下或者把输出写到文件里再tail别让旧错误干扰判断。坑二手滑把sources.list.d里的文件后缀写成了.list.bak。apt 只认.list结尾的文件改成.bak之后那个源就“消失”了不报错也不生效。这种“静默失效”比报错还难查因为它不给你任何提示。现在我改源文件都是先注释不轻易改后缀。坑三在一台 NAT 网络下的虚拟机上折腾了半天 DNS。那台机器的网关配错了resolv.conf里写的是宿主机内网 DNS但虚拟网桥没通。表现出来是解析超时我一开始以为是 DNS 服务器的问题换了三个公共 DNS 都没用。最后ip route一看默认路由压根不存在。这个坑告诉我解析失败之前先确认三层通不通ping网关比换 DNS 有用得多。坑四把apt-get update和apt-get upgrade混为一谈。update 只是刷新本地索引upgrade 才是真正升级软件。有人看到 update 报 100 就以为是系统升级失败跑去跑 upgrade结果因为索引是旧的装出来的版本不对。顺序永远是先 update 成功再 upgrade中间不要跳步。坑五以为免费源和企业源只能二选一。实际上你可以同时挂多个源只要它们指向的包不冲突就行。但从维护角度讲没必要同时挂因为 update 的时间会变长而且一旦某个源出问题整个 update 都会报 100反而增加了排查成本。我现在的原则是一台机器只保留真正需要的源越少越稳。5.3 新装节点到手后的标准收尾清单每次装完一台新的 Proxmox VE 7我现在会按这个清单走一遍基本能把后面可能遇到的坑提前填掉。第一步确认版本代号。cat /etc/debian_version和pveversion都跑一下确认是 11.x 和 7.x对应 bullseye。这一步花五秒能避免后面所有“代号写错”类的低级问题。第二步备份源配置。前面给过命令cp -a到/root/apt-backup留个后路成本几乎为零。第三步注释企业源和 Ceph 源添加免费源导入 release key。这四件事一次做完别留半成品状态。第四步校准时间。timedatectl set-ntp true等几秒确认同步成功。这一步很多人会跳过但它能挡掉一类很隐蔽的签名问题。第五步跑一次apt-get update确认没有E:行。如果只剩W:警告比如某些包的版本提示那是正常的不影响后续操作。判断标准是退出码为 0用echo $?确认一下最保险。第六步跑一次apt-get -y upgrade把基础组件升到最新。这一步在长期运行的节点上建议定期做但不要在业务高峰期做尤其是跑着虚拟机的宿主内核升级需要重启才能生效。提示内核升级完成后pveversion显示的是新版本但运行中的还是旧内核需要重启才切换。重启之前用uname -r和dpkg -l | grep pve-kernel对照一下确认新内核已经装好避免重启后进不去系统。第七步把整个过程记一笔。我会在/root下留一个setup-notes.md写清楚这台机器改了什么、为什么改、什么时候改的。这个习惯在机器多起来之后价值巨大因为半年后你根本不记得当初为什么注释了某个源有了记录就不用重新推理一遍。这件事花不了几分钟但能省下未来某个深夜的抓狂。最后分享一个我自己的判断习惯apt-get update报 100 的时候先别急着动手改任何东西把完整输出从头到尾读一遍找出所有带E:的行数一数有几条然后按“网络 → 源配置 → 签名与时间 → 环境状态”的顺序逐条处理每改一处重跑一次。这个过程看起来慢实际上比东改一下西改一下要快得多而且改完之后你对这台机器的状态是清楚的不是碰运气修好的。我踩过的那些坑八成都是因为跳过了“先把错误读全”这一步直接凭经验猜原因结果猜错了方向浪费的时间反而更多。
