网络安全工程师能力天花板：攻防、工程化与安全运营实践

开头先说个真事。几年前一次内部分享会上，一位做了十来年攻防的老兵抛出这句话：网络安全工程师是网安行业的天花板。台下当场有人不服，说不就是做做渗透测试、处理一下告警吗，凭什么叫天花板。他没争，直接把当天的工作清单投到屏幕上：凌晨两点处理一起异常外联告警，上午参加新业务架构评审，下午改一段检测规则压误报，傍晚和法务一起过数据出境的口径，中间还穿插着给两个业务团队回电话解释为什么这个需求不能这么做。散会没人再说话。

我想聊的就是这件事。网络安全工程师这个岗位真正"高"的地方，从来不在头衔，也不在薪资条上的数字，而在它对一个人的要求是复合型的：你得同时会说工程的语言、攻防的语言、业务的语言和协调的语言，少一套，这个岗位你就做不深、做不久。市面上讲安全的文章很多，讲"怎么学"的更多，但很少有人把"这个岗位到底难在哪、天花板是怎么被撑起来的"讲透。

下面我会把这四套语言拆开：岗位边界到底在哪、能力矩阵怎么一层层搭、一线每天在干什么、从别的岗位转进来要补哪些课、我踩过哪些坑。刚入行的新手能拿到一张相对清晰的路线图，已经在运维、开发、测试岗上想往安全方向靠的人，也能对照着看自己缺哪一块。

1. 先把"天花板"这个词说清楚：这个岗位到底高在哪

1.1 岗位边界：它既不是"装防火墙的"，也不是"只做渗透的"

很多人对网络安全工程师的想象停留在两个极端：要么觉得是机房里配策略的，要么觉得是拿着扫描器到处找洞的。这两个理解都不算错，但都只覆盖了这个岗位的一小块。

真实的岗位边界大致横跨四类工作。第一类是基础防护运维，包括边界策略、主机加固、身份权限、日志采集这些"地基活"，特点是重复、琐碎，但一旦缺位，后面所有高大上的东西都是空中楼阁。第二类是风险发现与验证，漏洞管理、渗透测试、代码审计、配置核查都属于这一类，核心不是"扫出多少条"，而是能不能判断哪些是真问题、哪些是误报、哪些虽然是真的但业务上可以接受。第三类是检测与响应，也就是常说的运营侧，规则调优、告警研判、事件处置、溯源分析，这部分对经验的要求最高，因为它是拿真实流量和真实攻击喂出来的。第四类是安全建设与治理，架构评审、需求评审、流程制定、合规落地、意识培训，看起来最"虚"，实际上决定了一个团队是天天救火还是稳步往前推。

这四类工作有个共同点：它们互相咬合。你只做漏洞扫描，不理解业务架构，就判不出优先级；你只做应急响应，不懂加固，同一个问题会反复发生；你只做合规，不懂技术细节，写出来的制度没人执行得下去。这就是为什么我说这个岗位的门槛不在单点技能，而在"能不能把四块拼成一个闭环"。行业里有个说法很形象：安全做得好的团队，看起来都很闲；安全做得差的团队，天天在打仗。差别就在这个闭环有没有合上。

1.2 四个维度看"高"：技术广度、责任权重、决策影响、成长曲线

说一个岗位是天花板，得有可衡量的依据。我一般从四个维度去看，这四个维度也是我带人时判断一个人到了什么水平的参照。

先说技术广度。这个岗位最反人性的一点是，你的知识面必须跟着攻击面走。业务上了云，你得懂云上的身份体系和网络模型；业务上了容器，你得懂镜像、编排、运行时；业务写了个新接口，你得看得懂那段代码在干什么。这不像某些岗位可以"一门技术吃到老"，安全这边是业务每往前一步，你的知识边界就得跟着扩一圈。这也是它被叫天花板的核心原因之一：它的能力上限不是由岗位定义的，是由整个技术生态定义的。

再说责任权重。我见过太多这样的场景：一条检测规则调得太严，业务侧一天几百条误报，运维直接把告警关了；调得太松，真出事的时候日志里什么都没有。这种"两头都是坑"的决策，在这个岗位上几乎每天都要做。而且安全事件的特殊性在于，它的后果往往不可逆——数据出去了就是出去了，删掉的日志找不回来。这就决定了这个岗位对人的心理素质要求很高：你得在信息不全的情况下做判断，还得为自己的判断负责。

决策影响这块，最典型的是架构评审。一个系统在设计阶段把权限模型想清楚，后面能省掉无数次补丁；设计阶段图省事用了共享账号，后面要花十倍的成本去拆。安全工程师在评审桌上说的一句话，价值可能等于后期一个月的整改工作量。但反过来，你要说得出这句话，就得看得懂架构图、读得懂数据流、算得清风险敞口。这就是为什么很多做了五六年的人会遇到瓶颈：技术操作层面已经很熟了，但一坐到评审桌上就插不上话。

最后是成长曲线。这个岗位不是线性增长的。前两三年你会觉得进步飞快，工具会用、漏洞会挖、报告会写，成就感很强。然后会进入一个平台期，感觉每天都在重复，学的新东西好像也没什么用。这个阶段是最容易流失人的。突破点通常不在技术本身，而在于你有没有开始从"做一件事"转向"设计一套机制"——从手动挖洞到建设一套漏洞管理流程，从天天处理告警到把某一类告警的误报率压到可接受范围。跨过这道坎，能力曲线会再陡一次。

2. 能力矩阵拆解：天花板是复合技能一层层堆出来的

2.1 地基三件套：网络、系统、代码，缺一样后面都会塌

我带过不少转岗的人，最常见的误区是一上来就奔着"高级攻防"去，结果地基是空的。地基就三样：网络、系统、代码。这三样不用学到专家级，但必须到"能独立排查问题"的程度。

网络这块，重点不是背 OSI 七层，而是能在脑子里还原一个数据包的完整旅程。一个请求从客户端发出，经过域名解析、建立连接、经过若干跳转、到达服务端、被反向代理转发、被应用处理、写进数据库、返回响应——每一环都可能出问题，也每一环都是攻击面。我一般要求新手至少能做到：看到一条告警里的五元组，能大致判断这是内网横向还是外联异常；看到一次连接超时，能分清楚是 DNS 问题、路由问题还是策略拦截。这些判断没法靠查文档速成，得靠实际抓包看。

系统这块，Linux 的文件权限、进程模型、日志位置、服务管理必须熟，Windows 的账户体系、组策略、事件日志同样要懂。原因很实际：应急响应的时候，你第一时间要回答的问题就是"这个东西是怎么起来的、以什么身份跑的、留下了什么痕迹"。不熟悉系统，你在机器上就是瞎转。我见过有人排查了半天，最后发现是自己不认识的某个系统服务在正常启动，白忙一场。

代码这块，不要求你能写业务系统，但要能读懂。至少要能看懂一段请求处理逻辑，知道参数从哪来、到哪去、有没有做校验；能看懂一段脚本在干什么；能自己写几十行的 Python 做日志清洗和批量处理。这条是我认为性价比最高的投入——会写一点代码的安全工程师，和完全不会的，效率差距是三倍以上，不是一点半点。

举个我自己常用的例子，处理一批访问日志找异常路径，用 shell 就能快速筛：

# 从访问日志里筛出状态码异常的请求，并按路径聚合计数 awk '$9 >= 400 && $9 < 500 {print $7}' access.log \ | sort | uniq -c | sort -rn | head -n 30

这行命令没什么技术含量，但它能在三十秒内告诉你"哪个路径在被大量探测"。如果你不会写，就只能一条条翻，或者等人给你做报表。日常工作中大量时间就消耗在这种小工具的有无上。

2.2 攻防视角：从"知道怎么防"到"知道怎么被打穿"

这是安全岗和普通运维岗最大的分水岭。运维的思维是"让系统正常跑起来"，安全的思维是"假设它已经被人盯上了，会从哪进来"。

培养这种视角，我的建议是从"复现"开始，而不是从"背漏洞"开始。找一个隔离的测试环境，把常见的问题类型自己动手走一遍：弱口令是怎么被撞开的、越权是怎么产生的、上传功能没做校验会怎样、接口没做频率限制会怎样。走一遍之后，你对"风险"这个词的理解会完全不一样——不再是清单上的一个条目，而是一条具体的路径。

这里必须强调一点：所有这类练习只能在你自己有完全处置权的隔离环境里做，不要去碰任何不属于你的系统，这既是职业底线，也是法律底线。行业里有句话：技术没有对错，但使用技术的人有。这条线必须刻在脑子里。

有了攻防视角之后，你看东西的方式会变。看到一个登录接口，你会先想它有没有做失败次数限制、有没有做账号锁定、密码传输是不是明文、返回信息会不会泄露账号是否存在。看到一个文件下载功能，你会先想文件 ID 是不是可枚举、有没有做归属校验、路径参数能不能穿越。这种"条件反射"不是天生的，是大量复现和复盘积累出来的。

下面这段是我经常用来做接口频率限制核查的简化脚本思路，纯粹是检测侧的辅助：

# 对自有测试环境的登录接口做失败次数上限核查 # 仅用于授权环境的健壮性验证 import time import urllib.request def probe(url, attempts=15): codes = [] for i in range(attempts): body = b'{"user":"probe_account","pass":"wrong_pass"}' req = urllib.request.Request( url, data=body, headers={"Content-Type": "application/json"} ) try: with urllib.request.urlopen(req, timeout=5) as r: codes.append(r.status) except Exception as e: codes.append(getattr(e, "code", "ERR")) time.sleep(0.3) return codes print(probe("http://test-env.local/api/login"))

看输出就能判断：如果连续十五次都是同样的返回，说明没有做失败限制；如果中途开始返回 429 或者账号被锁定，说明策略生效了。这种小脚本写起来十分钟，但比看十页配置文档直观得多。

2.3 工程化能力：把安全做成流水线，而不是消防队

这一层是很多人卡住的地方。技术到了能独立挖洞、能独立处置事件的水平，为什么还是升不上去？因为单点能力解决的是"这一次"，工程化解决的才是"下一次"。

所谓工程化，说白了就是把重复出现的判断变成规则，把规则变成流程，把流程变成系统能力。举个最朴素的例子：漏洞管理。手工做法是每隔一段时间扫一次，导出表格，挨个发邮件催修。这套流程跑三个月就会崩——因为扫描结果会越堆越多，业务方会越来越不配合，最后表格没人看。

工程化的做法是把整个链路拆开设计。资产要有准确的台账，扫描结果要能自动关联到责任人，优先级要有统一的计算口径，修复要有明确的时限和升级机制，复测要自动化。每一步都不难，难的是把每一步串起来并且让所有人遵守。我自己用过一个很粗糙的优先级算法，效果比拍脑袋强很多：

修复优先级 = 暴露面权重 × 可利用难度系数 × 数据敏感度 ÷ 修复成本

暴露面权重看这个资产是不是公网可达，可利用难度看是不是需要特定条件才能触发，数据敏感度看它上面有没有核心数据，修复成本看改动量有多大。四个值各自打个一到五的分，算出来的排序和实际风险排序的吻合度，比我一开始凭感觉排高得多。这个公式不精确，但它能逼着你在排序时说清楚理由——这一点比公式本身更重要。

工程化还有一个隐性收益：它让你的工作变得可衡量。你告诉老板"我很忙"没有意义，你告诉他"这个季度高危漏洞的平均修复时长从二十一天压到了七天"才有意义。而只有做了工程化，这个数据才拿得出来。

2.4 业务与合规语感：最难补，也最值钱的一层

如果说前三层是技术活，这一层就是"人"的活，也是我认为真正把大部分人挡在天花板下面的那一层。

技术出身的人容易有一个惯性：看到风险就想全部消灭。但现实是，业务有业务的节奏，资源有资源的约束，一个不影响核心数据的低危问题，在业务快速迭代期就是不值得停下来修的。这时候安全工程师要做的不是"坚持原则"，而是"说清楚代价"——不修的风险是什么、概率多大、最坏情况是什么、有没有成本更低的缓解手段。能不能把这个账算给业务方听懂，是分水岭。

合规这块也是同理。很多人对合规的理解是"填表交差"，其实合规要求的本质是把一些被反复验证过的最佳实践固化成流程。你理解了这个逻辑，就会发现合规和技术不是两张皮。比如访问控制要最小化、日志要留存足够时间、变更要留痕、敏感操作要双人复核——这些要求背后都是真实事故换来的经验。做技术的时候顺手把这些落地，合规检查的时候就不用临时补材料。

我在实际工作中养成的一个习惯是：每次评审完，除了给出技术结论，还会额外写三行——这个改动影响哪些数据、最坏情况是什么、如果他们决定不做我建议的加固，需要接受什么风险。这三行字往往比技术方案本身更被重视，因为它把决策权交回给了业务方，同时也把责任说清楚了。

3. 一线场景还原：一个安全工程师的一周是怎么过的

3.1 资产与漏洞管理：七成时间在打地基

很多人以为安全工程师每天都在做高难度对抗，实际上七成以上的时间花在很基础的事情上：盘资产、核配置、跟漏洞、写文档。听起来不酷，但这才是决定一个团队水平的地方。

资产台账这件事，做过的人都懂其中的痛苦。你问一个团队"我们有多少个对外服务"，十有八九答不上来，或者答出来的数字和实际差一大截。原因很简单：业务在不停地建、改、下线，而台账是人工维护的。我一般的做法是先做"被动发现"——从流量侧、从域名解析记录、从负载均衡配置、从云平台的资源列表里拉数据，交叉比对，找出台账里没有的、已经下线但还在解析的、解析到了但没登记的。这个比对过程通常能挖出百分之十几的"影子资产"。

漏洞管理同理。扫描器给出的原始结果往往有大量重复和误报，直接甩给业务方只会消耗信任。我习惯先做三轮过滤：第一轮去重，同一个组件同一个问题合并成一条；第二轮核验，对高危项做人工确认，把误报踢掉；第三轮定级，按前面说的优先级公式排序。三轮下来，原本几百条的结果通常能压到几十条真正需要处理的，业务方的配合度会明显不一样。

注意：漏洞报告的措辞很容易得罪人。同样一件事，"你们的系统存在严重漏洞"和"这个接口在特定条件下可能被绕过校验，建议本周内加一层归属判断"，后者的修复率能高好几倍。这不是话术问题，是专业性的一部分——你要能说清楚具体怎么改。

3.2 应急响应：凌晨两点的排查记录

应急响应是最能体现这个岗位价值的场景，也是最消耗人的。我印象比较深的一次，是某天夜里收到一条告警：一台内网服务器在凌晨一点四十左右，向一个陌生地址发起了持续的外连。

到现场之后的第一件事不是删文件，是保护现场。这个顺序很多人会搞反，一上去就杀进程、删可疑文件，结果痕迹全没了，事后复盘什么都说不清。我当时的处理顺序是这样的：

1. 先确认时间线。翻系统日志、登录日志、命令历史，把一点到两点之间这台机器上发生的所有动作按时间排出来。
2. 再确认入口。看这个时间段内有没有异常登录、有没有新起的进程、有没有可疑的计划任务或者自启动项。
3. 然后确认影响范围。这台机器上有什么数据、能访问哪些其他机器、有没有共享凭据。
4. 最后才做处置。隔离网络、保留镜像、清理、改密码、排查同类机器。

那次最后查出来是一个长期没人维护的测试服务，用的是默认口令，被人扫到之后挂了一个小程序，用来做外连。问题本身不复杂，但它暴露出来的东西很典型：一个没人管的测试服务，因为不在台账里，所以从来没被扫描过，也从来没被加固过。

处置完之后我做了一件事，把这次的时间线、判断依据、每一步的取舍都写成了一份复盘，重点不是"我们多快解决了"，而是"为什么这个资产会漏在台账外面"。复盘的产出必须落到机制上，否则下次还会发生。那次之后我们加了一条规则：所有新申请的资源，必须带责任人标签，没有标签的一律不允许上线；每季度做一次标签完整性核查。

日志研判这块，我常用一些简单的聚合来快速定位。比如从认证日志里找异常登录：

# 统计每个账号的登录失败次数，找出被反复尝试的账号 grep "Failed password" /var/log/auth.log \ | awk '{for(i=1;i<=NF;i++) if($i=="for") print $(i+1)}' \ | sort | uniq -c | sort -rn | head -n 20

如果有审计平台，用 SQL 拉时间线会更方便：

-- 按主机拉取某时间段内的关键事件时间线 SELECT event_time, host_id, event_type, src_ip, account, detail FROM security_events WHERE event_time BETWEEN '2024-05-11 01:00:00' AND '2024-05-11 03:00:00' AND host_id = 'host-xxxx' ORDER BY event_time ASC;

这两段都不复杂，但应急的时候能省下大量翻页的时间。排查的本质是把零散的信息排成一条能自洽的时间线，工具只是加速这个过程。

3.3 安全建设与评审：把问题拦在图纸上

第三个高频场景是评审。前面说过，安全工程师在评审桌上的一句话，可能顶后期一个月的整改。这个场景看起来最不"技术"，但恰恰是这个岗位最能产生杠杆的地方。

我参加评审一般看四件事。一是数据流，数据从哪来、到哪去、中间经过哪些组件、哪些是明文。二是信任边界，哪些调用是跨域的、跨网络的、跨账号的，边界上的校验是否都在。三是权限模型，谁能访问、授权粒度是账号级还是资源级、有没有做归属判断。四是可观测性，出问题的时候能不能查到、日志够不够、告警有没有。

这四项不需要你懂具体业务逻辑，但能覆盖大部分会出事的点。我有个习惯，评审的时候不追求把话说满，而是把"如果在某个位置加一层判断，成本大概是多少"说出来，让对方自己权衡。那种一上来就说"这样不行，必须改成 XXX"的评审风格，通常结果是被绕过。

真正好的状态是：业务方在画架构图的时候就会主动来找你，因为他们知道你能帮他们省事，而不是给他们添堵。

4. 转型路线：从运维、开发、测试跨进来要补哪些课

4.1 三条可行路径，以及各自的成本

想进这个方向的人，背景大多是三类，路径不完全一样。

运维转安全是最常见的路径，因为底子最接近。运维对系统、网络、服务部署都很熟，缺的主要是"攻击者视角"。我建议这类人从加固和处置入手，比从挖洞入手更顺，因为加固本身就是运维工作的延伸，只是从"让它跑起来"变成"让它跑得安全"。

开发转安全的优势是代码能力强，看代码审计、看业务逻辑问题特别有优势，往应用安全、安全研发方向发展很合适。短板是系统和网络底层，遇到需要登机器排查的场景容易卡住。建议补一补操作系统和网络协议，多在生产环境里泡一泡。

测试转安全是很自然的延伸，因为测试本来就是在找问题。需要补的是深度——功能测试关心的是"功能对不对"，安全测试关心的是"不按设计的方式用会怎样"。

4.2 学习顺序：先宽后深，别一上来就啃大部头

这块我给的建议可能和很多人不一样：不要一上来就买一堆厚书从头啃。大部头是给人查的，不是给人读的。

我的建议顺序是这样。第一步用两三周时间建立全景认知：搞清楚这个领域有哪些方向（应用安全、数据安全、主机安全、云安全、安全运营等），每个方向大概做什么。第二步选一个和现有工作最接近的方向深进去，比如做后端的就从应用安全开始，做运维的从主机和网络安全开始。这个阶段的目标不是"学完"，是"能在一个具体场景里独立完成任务"。第三步是横向扩展，在实践中遇到什么补什么。

学习材料的选择上，我推荐优先看官方文档和社区里的实战复盘，而不是"教程"。实战复盘的价值在于它记录了判断过程——为什么当时这么想、后来发现错在哪。这种信息在教程里是没有的，但恰恰是最有价值的。

4.3 简历与面试：怎么讲项目才像真的做过

这块我面过不少人，说几个很实在的观察。

第一，别把"用过工具"写成"做过项目"。"使用扫描器完成漏洞扫描"这种描述，面试官看一眼就过去了，因为它体现不出任何判断。有说服力的写法是："针对某业务系统做了一轮安全检查，共发现若干项风险，其中高危若干项，主导完成了其中影响面最大的两项的整改，整改后复测通过。"区别在于，后者有判断、有推动、有结果。

第二，一定要准备"你判断错的时候"这个问题。几乎每次面试我都会问：讲一个你判断失误的案例。答"我没失误过"的基本直接淘汰，因为这说明要么没做过真事，要么不具备反思能力。好的回答通常是：当时基于什么信息做了判断、后来发现漏了什么、之后怎么调整了方法。

第三，技术问题多半会往深里追。你说了做过应急响应，下一步就会问你那次事件的时间线、你的判断依据、有没有考虑过其他可能性。答不上细节，就说明那个项目你只是参与过，不是主导过。所以简历上写的东西，必须是你真的能讲二十分钟的。

提示：简历上不要写任何你不具备完全处置权的项目细节，尤其是涉及具体单位信息的部分。讲方法和结果，不讲客户的敏感信息。这既是职业素养，也是基本的分寸。

5. 踩坑实录：新手最常摔的五个跟头与排查思路

5.1 五个典型坑，每一个我都见过不止一次

第一个坑：把扫描结果当成风险清单。扫描器只会告诉你"这里可能有问题"，不会告诉你"这个问题的实际影响是什么"。我见过有人把扫描报告原样转发给业务方，结果几百条里一大半是误报，业务方从此对安全团队的输出一律打折扣。正确做法是：扫描只是输入，人工核验和定级才是产出。

第二个坑：应急响应先动手后取证。前面说过，一上来就删文件杀进程，痕迹全毁。正确的顺序永远是先保护现场、记录现状，再做处置。哪怕当时判断就是个大马蜂窝，也要先把内存、进程列表、网络连接、关键日志留存下来。

第三个坑：加固改成"关服务"。有些问题不好修，最省事的办法就是把功能关掉。这在短期有效，但会严重影响业务方对安全团队的信任，长期看是把自己的路走死。加固的原则应该是"在保证功能的前提下降低风险"，实在要牺牲功能，也得说清楚代价并让业务方同意。

第四个坑：只盯技术，不看流程。同一个问题在三个系统上重复出现，很多人第一反应是"修三次"，正确的反应是"为什么流程上没有拦住"。这个思维转换，是从执行者走向设计者的关键一步。

第五个坑：忽视文档。我吃过这个亏。一次处置完之后没写复盘，半年后同类问题再次出现，当时怎么处理的、为什么那么处理，全忘了，从头再来一遍。从那以后我给自己定了规矩：任何一次非例行处置，必须在四十八小时内写完复盘，哪怕只有半页。

5.2 常见问题速查表

这张表我一般会给新人当参考，但会强调一句：表里的"可能原因"只是起点，不是答案。真实的排查永远是先看数据、再形成假设、然后验证假设，而不是拿着表去对号入座。

6. 天花板之后：这个岗位的长期走法

6.1 技术专家、安全架构、管理，三条线各有各的难

做到一定年限之后，路径大致分三条。

技术专家线是最纯粹的，往某个细分方向扎深，比如应用安全、数据安全、攻防对抗。这条路的天花板很高，但要求也高——你得在某个领域里成为别人遇到问题第一个想到的人。这条路的难处在于，越往深走，能交流的人越少，容易陷入自我怀疑，需要很强的自驱力。

安全架构线是从"解决具体问题"转向"设计整体方案"。这条路要求你有全局视角，能在一个复杂系统里权衡各种约束，还要能说服各方接受方案。它的难度不在技术，在于要在信息不完整、资源不充分的情况下做出可执行的决策。

管理线是从"自己做"转向"带人做"。很多人以为管理是技术的降级，其实不是，它是另一套能力：怎么定目标、怎么分资源、怎么在压力下保住团队的节奏。我带过团队之后最深的一个感受是，管理最大的挑战不是教别人怎么做，而是忍住不自己上手。

三条线没有高下之分，但我建议不要过早锁定。前五年尽量把技术底子打厚，后面转哪条都有底气；反过来，技术没打牢就转管理，很容易变成只会开会的中层。

6.2 我对"天花板"这两个字的真实理解

回到最开始那个问题。为什么说网络安全工程师是网安行业的天花板？我的理解是，这个岗位的能力上限不由岗位本身决定，而由它必须面对的复杂性决定。你得懂技术，但光懂技术不够；你得会沟通，但光会沟通也不行；你得能扛责任，还得能在信息不全的时候做判断。这几样凑齐的人本来就不多，所以显得稀缺。

但我不太喜欢"天花板"这个词带来的另一个暗示——好像到了这个位置就到头了。实际做下来，我越来越觉得这个岗位更像一个入口，它让你同时接触到技术、业务、风险和决策，你从任何一个方向往外走都能走很远。

最后分享一个我自己一直在用的习惯：每个季度挑一件做过的事，重新想一遍——如果重来一次，哪一步会做得不一样。这个复盘不需要写给别人看，纯粹是给自己。我做这个练习最大的收获是，很多当时觉得"没办法只能这样"的选择，事后看其实是有别的解法的，只是当时没想。这个习惯坚持几年下来，比看多少本书都管用。