ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Windows防火墙端口封禁实战:从概念到命令,彻底搞懂禁用端口

Windows防火墙端口封禁实战:从概念到命令,彻底搞懂禁用端口 1. 先搞清楚禁用端口到底想解决什么问题接到过不少类似的活儿把这台 Windows 服务器的 XX 端口禁掉。我第一次听到这话差点直接去防火墙里新建一条阻止规则但多问了一句才发现对方想解决的根本不是同一件事。有人是端口被占用了想腾出位置有人是担心外部扫描才想封口子还有人是要禁止某个软件悄悄联网。需求没对齐之前任何禁用端口的操作都可能白费。所以这篇文章我不会上来就给命令和截图而是先把几个容易混淆的概念拆开。毕竟在 Windows 防火墙里做端口封禁本身不难真正难的是搞清楚你要对付的是什么流量、从哪个方向来、封了之后会不会把自己也锁在门外。下面这些内容既适合刚接触 Windows 防火墙的新手也适合给服务器做安全加固的运维参考按你自己的场景挑着看就行。1.1 端口本身没有开关防火墙规则才是那扇门很多新手会有个误解以为端口像水龙头一样有个关闭旋钮。实际上端口是操作系统为网络通信分配的一个数字标识它不是独立进程也不是可以随手关掉的系统组件。真正在端口上值班的是某个服务进程比如远程桌面服务监听 3389Web 服务监听 80SSH 服务监听 22。所以当你访问一个 IP 地址的某个端口时实际上是在尝试和这个监听的进程握手。禁用端口这个操作本质上不是在系统里删除某个端口而是告诉 Windows 防火墙凡是匹配到这个端口的网络数据包统统按阻止处理。你可以把端口想成小区里的门牌号服务是房间防火墙就是小区门口的保安。你要做的不是拆掉门牌号而是跟保安说清楚这个门牌号不允许外面的人进或者不允许里面的人出。这个理解很重要因为它决定了后面所有操作的正确方向。1.2 端口被占和端口被封是两码事我先说一个最常见的误区有人喊关闭占用的端口其实他想解决的是启动程序时报错端口被占用。比如 Elasticsearch、HBase、Tomcat 经常出现这类问题。这时候正确的处理方式是找到占用端口的进程然后结束它或者改服务配置而不是建防火墙规则。为什么因为防火墙规则挡的是外部流量服务进程本身还赖在端口上系统内部的端口占用状况一点没变。查找占用进程在 Windows 上用两条命令基本就够了netstat -ano | findstr :8080 taskkill /F /PID 12345第一条命令会列出监听 8080 的进程 PID第二条把对应进程强制结束。注意这里的 PID 是进程标识不是端口号别搞混了。还有些人会去防火墙里建一条阻止规则结果发现程序还是报端口被占用原因就在于此你封了外部访问但本地进程依然活着端口依然被它占着。端口被封则完全是另一码事。它是指防火墙拦截了对该端口的连接请求外部访问不了但端口监听可能依然存在。举个例子你把远程桌面 3389 通过防火墙禁掉了但netstat -ano一看3389 还在 LISTENING 状态因为远程桌面服务还在跑。这种情况下服务没有停止只是网络层面被切断了。所以遇到问题时你先要判断自己是要杀进程还是断网络选错工具问题永远解不掉。常见现象真正问题推荐手段服务启动报端口被占本地进程占用端口netstat taskkill外部访问某端口不通监听服务未启动或防火墙阻断查服务状态配防火墙规则某程序偷偷往外连出站流量没有被限制建出站阻止规则测试时只想临时断掉端口需要短时间阻断流量防火墙规则用完删除1.3 Windows防火墙的默认策略决定了你该用白名单还是黑名单很多人一提到防火墙脑子里就是黑白名单四个字。Windows 防火墙虽然没有一个独立的配置文件叫黑名单但它的规则天然就分为两类允许规则和阻止规则。允许规则就是白名单思路阻止规则就是黑名单思路。关键要看 Windows 防火墙的默认策略是什么。默认情况下Windows 防火墙对入站流量是默认阻止除非有明确的允许规则对出站流量是默认允许除非有明确的阻止规则。也就是说你新装一台 Windows 服务器只要防火墙开着外部默认连不进来但本机程序默认可以随便往外连。这两种默认策略决定了你的操作方向如果只是想封一个入站端口建一条阻止入站规则就够了如果想要限制本机程序外联光靠默认就不行必须主动建出站阻止规则。我之前帮人做过一个安全加固对方说把服务器上的危险端口都封掉我就问了一句要不要连出站一起封他犹豫了。后来我们发现服务器上有几款软件会周期性连回厂商服务器做遥测建了对应的出站阻止规则之后外联立刻安静了。所以我一直建议做端口封禁之前先想清楚你是在做门禁管理还是出行管制这两个方向对应完全不同的规则配置。2. 入站和出站封禁方向决定安全半场2.1 入站规则管的是谁能从外面连进来入站流量指的是外部设备主动发起连接、访问你本机端口的数据包。比如你在家里用电脑远程连公司服务器的 3389流量方向就是入站别人访问你服务器上的网站 80 端口也是入站。配置入站规则就是在回答一个问题允不允许外面的人主动来找你。Windows 防火墙默认会阻止所有未经允许的入站连接。所以你经常会遇到一种情况明明服务起来了端口也监听了但从局域网另一台机器就是连不进来。这时候十有八九是防火墙规则没放行。很多应用安装包在安装时会自动注册入站允许规则比如游戏、远程工具等如果你用的是绿色版软件或者自己写的服务通常不会自动放行就得手动加允许规则。反过来如果你要禁用端口目的又是禁外部访问那就应该建一条入站方向、阻止动作的规则。举个例子某台服务器被扫描了 445 端口你为了预防直接把入站 445 封掉。外部访问瞬间断开但本机 SMB 相关服务可能还在运行。这种做法的好处是快速止血坏处是如果服务器里有合法服务也用到 445比如共享文件那这些功能也就一起废了。所以封入站端口之前一定要先盘点清楚这个端口被谁用着。2.2 出站规则管的是本机主动联出去出站流量指的是本机主动向外部发起的连接。比如浏览器打开网页时连远程服务器的 443软件检查更新时连厂商服务器的某个端口这都属于出站。Windows 防火墙默认放行所有出站流量也就是说只要程序能运行起来它想往哪连就往哪连系统不会拦着。这个默认策略在很多时候是方便但也最容易藏安全问题。恶意软件、挖矿程序、广告插件甚至某些正版软件的强制遥测都需要靠出站连接来工作。你封了入站外面的进不来但里面的一旦被种了东西它照样可以往外传数据。所以我做安全加固的时候从来不会只盯入站出站方向至少要给关键程序单独建规则。出站封禁可以按端口封也可以按程序封。按端口封适合那些目标端口固定的流量比如某个程序定期往 192.168.1.5 的 9000 端口发数据你直接封出站 TCP 9000 就很有效。按程序封适合目标端口经常变的流量比如浏览器、办公软件会在多个端口之间切换这时候封端口根本封不住应该新建程序规则指定某个 exe 禁止出站。网上经常有人问怎么屏蔽 acrobat.exe 联网本质上就是建一条出站阻止规则程序定位到 Acrobat.exe而不是去封某个端口。2.3 为什么入站也封、出站也封才算彻底禁用很多人在防火墙里只建一条入站阻止规则就以为端口已经禁用了。但你要明白同一个端口号在不同场景下可能是完全不同的两种流量。以 22 端口为例它最常用的是 SSH 远程管理。如果攻击者从外面扫你的 22这是入站流量但如果你本机被入侵后恶意程序主动往外面的某个 22 端口连建立反向隧道这是出站流量。你只封入站 22恶意程序的出站依然畅通。所以如果你真正想把这个段位彻底切断最稳妥的做法是入站、出站各建一条阻止规则。我在帮客户做基线加固时习惯用命名区分比如Block_IN_TCP_22和Block_OUT_TCP_22两条都配好后对这个端口来说本机和外界的联系才算真正断了。当然出站封禁要谨慎尤其是服务器还要访问更新源、数据库、备份系统的时候别一刀切把必要的出站流量也砍了。封之前最好用抓包或者 netstat 观察几天确认它的连接规律。3. 图形界面下新建一条端口封禁规则3.1 向导里最容易选错的三个地方图形界面操作看似简单但每一步都有很多人选错。打开方式按 Win R 运行wf.msc打开高级安全 Windows Defender 防火墙左侧点击入站规则右侧点击新建规则。这一步就分出了方向如果刚才你想的是入站就点入站规则如果是出站就点出站规则。接下来进入规则类型页面选端口。这一步没人会选错但从协议和端口页开始就容易踩坑了。第一个坑是协议选择。一个规则里只能选 TCP 或 UDP 中的一种不能同时覆盖。很多服务同时监听了 TCP 和 UDP比如 DNS 协议默认用 UDP但它也有 TCP 版本RPC 类的服务则经常在两套协议上都有监听。所以你要封一个端口很可能需要创建两条规则一条 TCP、一条 UDP。别嫌麻烦漏一条就等于没封干净。第二个坑是特定本地端口和特定远程端口的区分。这是新手重灾区。你要禁止外部访问本机的 3389连接的对端是外面的客户端本机是被访问方所以应该填特定本地端口 3389你要禁止本机访问某个外部 IP 的 22 端口那本机是发起方对端 22 是远程端口应该填特定远程端口。很多人一看到远程两个字就以为是要封外部访问结果把规则的方向搞反了。第三个坑是操作页面里的阻止连接和允许安全连接。“允许安全连接”涉及 IPsec 身份验证日常封端口几乎用不上选择阻止连接就好。如果误选了允许安全连接规则会要求连接必须经过 IPsec 加密保护看上去可能达到了不允许普通连接的效果但和阻止语义完全不同排查时非常容易懵。3.2 端口范围的写法与协议细节在特定本地端口或特定远程端口的输入框里Windows 防火墙支持三种写法单个端口、多个端口、端口范围。比如3389 80,443,8080 135-139多个端口之间用英文逗号分隔范围用短横线连接也可以混合写比如80,443,8000-9000。但我不建议把范围写得太大因为范围越大误伤的流量越多。比如你要封的是 8080 端口的服务随手写了个 8000-9000结果同网段其他服务也被影响了这种案例我见过不少。另外要注意一点端口规则里填写的端口号是目标端口还是源端口取决于你当前是入站还是出站。入站规则里的本地端口对应的是服务监听端口也就是你对外提供服务、或者被攻击的端口出站规则里的远程端口对应的是你要禁止访问的外部端口。区分清楚了就不会出现明明封了还是能连的诡异情况。3.3 作用域和配置文件决定规则在哪些环境生效向导做到配置文件页面会出现三个勾选框域、专用、公用。这是很多人忽视了细节。Windows 会根据当前网络位置把网络分成域、专用、公用三种配置文件。如果你只勾选了公用那么当电脑接在标为专用的网络里时这条规则不生效端口依然暴露。我的建议是如果是封禁安全风险端口三个配置文件全勾上防止换了个网络环境后规则失效如果你是在公司域环境里且域策略已经有更细的控制也可以让域管理员通过组策略下发放置规则本地手工规则可能会和组策略冲突。单机用户无脑全勾就行问题不大。再往下是作用域设置也就是此规则应用于哪些 IP 地址。默认任何 IP 地址是可以的但如果你只想封某个来源 IP比如某台扫描器不断攻击你的 22 端口你可以在远程 IP 地址里填那个攻击者的 IP只对它的流量执行阻止其他合法来源不受影响。这比一味整体封端口要精细得多也更适合生产环境。注意这里的本地 IP 地址一般默认即可不需要刻意设置。3.4 别动不动就关闭防火墙有段时间网上一搜尽是关了防火墙就通了的说法。确实关闭防火墙能解决所有端口不通的问题因为系统不再过滤任何流量了。但我必须说这是一种很危险的操作尤其对服务器来说。Windows 防火墙不仅仅是挡几个端口它还负责网络访问保护、IPsec 策略、入站出站规则等一系列安全机制。关闭后依赖系统服务的网络策略可能失效一些应用的检测也会异常。而且很多人关了防火墙之后过几个月就忘了这件事直到服务器被爆破成功才后悔。我遇到过不少客户远程桌面登不上去第一反应就是关防火墙问题是关了之后反而更不敢重启了——因为重启后没有防火墙保护服务器裸奔在公网上。正确做法是如果真的只是某个端口不通先看服务监听再查防火墙规则要么放行明确需要的端口要么把该封的封住。端口不通不等于防火墙乱封更不等于防火墙不可用。关闭防火墙有没有影响这个问题答案一定是有影响而且还挺大。宁可多配几条精确规则也不要用全局开关来省事。4. 用命令行实现批量端口封禁与快速部署4.1 netsh 一条命令封掉一个端口图形界面适合单机偶尔操作但如果你有几十台服务器要统一加固或者在远程终端里操作命令行才是效率之王。Windows 自带的netsh advfirewall命令可以完成绝大部分防火墙配置。封入站 TCP 8080 端口命令长这样netsh advfirewall firewall add rule nameBlock_IN_TCP_8080 dirin actionblock protocolTCP localport8080这里的参数拆开看其实很好记dirin表示入站actionblock表示阻止protocolTCP指定协议localport8080指定本地端口。如果你要封出站就把dirin改成dirout。命令执行完毕后在wf.msc里刷新就能看到这条规则。查看规则是否添加成功netsh advfirewall firewall show rule nameBlock_IN_TCP_8080删除规则netsh advfirewall firewall delete rule nameBlock_IN_TCP_8080注意删除命令如果只给部分参数可能一次性删除多条规则。比如你只写netsh advfirewall firewall delete rule nameall那会把所有规则删光。所以命名一定要有规律删的时候精确指定规则名。4.2 用脚本批量封禁一组高危端口批量封端口是命令行最有价值的使用场景。比如新装了一台服务器你希望把常见高危端口一次性全部阻止可以用 PowerShell 跑一个循环。我的习惯是把端口清单放到一个数组里协议循环 TCP 和 UDP这样一条脚本就能覆盖绝大多数情况$ports 22,23,135,139,445,3389 $protocols TCP,UDP foreach ($proto in $protocols) { foreach ($port in $ports) { New-NetFirewallRule -DisplayName Block_IN_${proto}_$port -Direction Inbound -Action Block -Protocol $proto -LocalPort $port -Profile Any } }这里用了New-NetFirewallRule是比 netsh 更现代化的管理方式。脚本跑完后用Get-NetFirewallRule -DisplayName Block_IN_TCP_22能验证规则。中途想改某条规则可以用Set-NetFirewallRule调整参数比如把Action从Block改成Allow。这套逻辑中端口清单可以按业务定制。比如你要给 HBase 集群做安全策略就把 HBase 需要用到的端口列进清单只放行到自己内网网段其余全部阻止给 Elasticsearch 做同样处理也可以。只要把端口数组换掉代码本身不需要大改。这也是我推荐用脚本而不是手工一条条点的原因可重复、可审计、不容易漏。4.3 规则命名、导出导入与备份规则命名这个事刚开始觉得无所谓规则多了以后才知道有多重要。你维护的是生产服务器几个月后回来看到一堆名叫新建规则 1的条目根本不知道当时为什么建。到那时候删也不是、留也不是。我建议的命名格式是Block_方向_协议_端口_用途_日期。比如Block_IN_TCP_3389_RDP_harden_20250101一眼就能看出这是 2025 年 1 月 1 日做的远程桌面入站封禁。出站规则同理Block_OUT_TCP_443_AppTelemetry_20250101。虽然名字长但给后续接手的人省了大量时间。整体备份和迁移也很重要。Windows 防火墙提供了导出功能netsh advfirewall export C:\backup\firewall-rules-20250101.wfw恢复的时候用netsh advfirewall import导入这个.wfw文件。有一个坑我必须提醒导入操作会覆盖当前所有防火墙配置而不是增量合并。所以导入之前一定要先把当前规则也导出备份一份。否则你辛苦配了一年的规则导入同事的旧配置全部没了到时候哭都来不及。4.4 关于规则优先级很多人理解反了经常有人问如果我同时建了一条允许规则和一条阻止规则哪个生效网上说法很多但大多数场景下Windows 防火墙的原则是阻止规则优先于允许规则。也就是说只要哪条规则明确匹配了当前流量且动作是阻止即使存在允许规则流量也会被拦下来。但实际排查中我发现很多封了没生效的案例根源根本不在优先级而是规则本身没有真正匹配流量方向。比如你在入站规则里封了 TCP 8080但实际服务是 UDP 8080或者你封了远程端口而不是本地端口这些情况下规则都在但它不会拦截目标流量。所以先别怀疑优先级先老老实实检查方向、协议、端口号这三个要素是否匹配。还有一个容易混淆的点如果系统里配置了 IPsec允许安全连接规则会区分加密流量和普通流量视觉上可能看到允许规则生效的结果。这已经超出普通端口封禁范畴我建议在不熟悉 IPsec 的情况下统一选阻止连接或者允许连接就好避免引入不必要的复杂性。5. 封完以后端口照样通的排查链路5.1 从外到内逐层检查的排查顺序端口封禁后依然能连通这是大家问得最多的问题。每次排查我都按固定顺序走能省很多时间第一步确认规则存在且已启用。在wf.msc里找到对应的规则看已启用列是否是是。脚本创建的规则默认启用但也有可能被后续操作或组策略禁用。第二步确认方向正确。你是要阻止外部连进来还是阻止本机连出去规则方向是否和流量方向一致这一步出错率最高。第三步确认协议匹配。TCP 流量需要 TCP 规则UDP 流量需要 UDP 规则。服务监听的是哪个协议别想当然。第四步确认端口匹配的是本地端口还是远程端口。特别是新建规则时选错远端/本地常见到不能再常见。第五步确认配置文件覆盖了当前网络位置。比如当前网卡被识别为公用你的规则只勾了专用那就不会生效。第六步查看服务监听状态。用netstat -ano | findstr 端口号确认端口还在监听。如果服务已经停了那端口本来就不通你封的规则用不上。我画过一张简单的自查单子放在运维文档里每次遇到端口还通的问题就按这个顺序过一遍绝大多数都能在十分钟内定位。不要一上来就怀疑系统有后门那是最后才考虑的事。5.2 防火墙打开后连 ping 都不通不代表端口被禁用很多人在测试端口封禁时习惯用 ping 来验证。比如封了 3389然后去 ping 那台服务器发现 ping 不通以为防火墙把所有流量都禁了。其实这是一个常见误区ping 用的是 ICMP 协议不是 TCP也不是 UDP。Windows 防火墙默认会阻止 ICMPv4 回显请求所以即使你只封了 3389ping 一样不通。这跟端口封禁没直接关系。如果你就是想开放 ping 给网管监控用可以单独放行 ICMPnetsh advfirewall firewall add rule nameAllow ICMPv4-In protocolicmpv4:8,any dirin actionallow执行完之后其他端口该封的还是封着但 ping 能通了。所以说验证端口封禁效果不能用 ping 来代表一切得用具体的端口探测工具。5.3 遇到 0x800706d9 错误时先修服务再谈规则有段时间不少朋友反馈win11 里打开 Windows 防火墙或者新建规则时弹窗提示错误代码 0x800706d9。这个错误基本可以断定是防火墙相关的依赖服务没有正常运行。Windows 防火墙不是独立工作的它依赖好几个底层服务其中最核心的是 Base Filtering Engine (BFE) 和 Windows Defender Firewall (MpsSvc)。如果这两个服务被禁用、停止或者被第三方安全软件接管就会出现这个错误。修复步骤很简单按 Win R输入services.msc回车打开服务面板。找到Base Filtering Engine右键属性启动类型改为自动然后启动它。找到Windows Defender Firewall同样改为自动并启动。以管理员身份打开命令提示符执行net start BFE和net start MpsSvc确认服务已经启动。如果提示依赖服务或组无法启动再去检查 Remote Procedure Call 和 DCOM Server Process Launcher 服务是否正常。修复完服务后再去建规则0x800706d9 基本就消失了。需要提醒的是有些第三方杀毒软件会接管 Windows 防火墙这时你把 BFE 启用了也可能被接管策略覆盖最好到第三方软件的控制台里去调整防火墙状态。5.4 把自己锁在外面管理端口封禁前的自救我记得第一次给远程服务器封 3389 时手一抖规则写成了全局阻止点完确定整个 RDP 会话瞬间断开。我当时心里一凉幸好那台机器还有带外管理界面折腾了半小时才恢复。这个教训让我养成了一个习惯管理端口封禁前一定要留后路。如果在远程操作时必须封禁 3389、22 这些管理端口有几种自救方案。第一种不要全局封而是只封某个恶意来源 IP不影响自己的管理地址第二种如果你确实要全局封先创建一个临时计划任务让它在一分钟后自动删除这条规则这样即使你把自己锁在外面一分钟后也会自动恢复第三种最好在机房层面或者云平台控制台保留 VNC、串口之类的带外访问通道以备不时之需。顺带说一下22 端口是 SSH 服务的默认端口Windows 上如果安装了 OpenSSH Server也默认监听 22。很多人搞不清楚 22 和 3389 谁是哪个服务的把 22 当成远程桌面端口直接封了结果 SSH 连不上。其实 22 管的是 SSH3389 管的是 RDP它们是两个完全不同的远程管理服务。封端口前先通过netstat -ano确认端口号和对应服务的对应关系。6. 验证封禁效果与规则日常运维6.1 别在本机自测从外部验证才靠谱建好规则后最忌的是在本机上拿localhost或者本机局域网 IP 去测试。Windows 防火墙对回环访问loopback有特殊处理本机访问本机往往不走正常的入站规则测出来全是通的根本不能反映真实效果。正确做法是在另一台机器上测试。比如你要验证服务器 3389 是否已被封禁可以在另一台 Windows 机器上执行Test-NetConnection 192.168.1.10 -Port 3389这条命令会尝试建立 TCP 连接到目标 IP 的 3389 端口。如果输出里的TcpTestSucceeded : False说明连接没成功。不过要注意Windows 防火墙阻止流量时对 TCP 连接通常表现为超时或直接丢弃不一定会给你明确的拒绝回应。所以看到超时反而说明规则可能在起作用不能简单归因为网络故障。云服务器还要多检查一层云平台的安全组。安全组是云厂商在虚拟网络层面做的过滤Windows 防火墙是操作系统内部的过滤两者是独立的两道关卡。即使你在 Windows 里封了端口安全组依然可能放行反过来也一样安全组拦住了端口你 Windows 里的服务怎么改都白搭。所以生产环境做端口封禁至少要同时看这两个层面。6.2 开日志让防火墙把命中的封禁记下来有时候你搞不清一条规则到底有没有拦截流量最好的办法是让防火墙自己写日志。Windows 防火墙支持把被阻止的流量记录到日志文件默认路径是C:\Windows\System32\LogFiles\Firewall\pfirewall.log。用命令行开启记录被丢弃流量netsh advfirewall set currentprofile logging filename C:\Windows\System32\LogFiles\Firewall\pfirewall.log netsh advfirewall set currentprofile logging maxfilesize 32767 netsh advfirewall set currentprofile logging droppedconnections enable之后去看日志会看到类似DROP字样的记录后面跟着时间、源 IP、目标 IP、端口等信息。这就是规则命中的直接证据。有了日志排查为什么封了还是通为什么某个 IP 一直在扫描都变得有据可查不用靠猜。需要注意的是日志文件不能无限变大maxfilesize我一般设成 32 MB 就够用了。生产环境建议把日志路径放到非系统盘避免系统盘满了导致麻烦。6.3 端口封禁清单的命名与导出维护最后聊聊长期维护。我做过的项目里防火墙规则经常是最容易腐烂的配置之一当初封了什么、为什么封、谁封的没人说得清。有些规则在系统升级后失效有些端口早就没人用了但规则还挂在那里。所以我强烈建议维护一份端口封禁清单用表格记录端口号、协议、方向、用途、创建人、日期、关联工单号。规则命名也要统一比如Block_IN_TCP_3389_RDP_harden_20250101让规则本身自带说明。定期导出规则做备份同样重要。服务器出问题或者要重建的时候一份干净的防火墙配置能省下一整天时间。我通常习惯每个季度做一次netsh advfirewall export把.wfw文件放到配置管理库里。导入时要记住它是覆盖式恢复别把当前规则弄丢了。最后再说一点个人体会端口封禁只是网络安全里最基础的一步它解决的是快速止血的问题并不能替代真正的服务收敛。我见过很多团队一边不停加防火墙规则一边让开发把服务监听在 0.0.0.0整个网络暴露面大得离谱。我的习惯是先用防火墙规则做应急阻断然后推动服务改成只监听内网地址、或者改掉默认端口再配合必要的账号和补丁管理。毕竟防火墙规则叠得再多也顶不上一个本就不该暴露的端口从源头消失。希望这篇经验能帮你把禁用端口这件事做得既快又稳别在被锁定之后才想起还有这些坑。
返回列表