网络排障核心:交换机MAC地址表、ARP与默认路由的转发原理

如果你跟我一样,读《网络是怎样连接的》这类经典网络入门书时第一遍大概率是“看懂了,但机器一坏还是不会排障”,第二遍才会真正开窍。前面两篇“核心框架版”我们走完了两段路:浏览器输入网址后,DNS 如何解析出 IP、HTTP 请求如何交给套接字;操作系统协议栈如何把数据切成 TCP 段、加上 IP 头、再由网卡芯片转成电信号送上网线。现在到第三篇,重点就是电信号离开网卡之后的故事——网线、交换机、路由器,以及你身边那些“什么都不动,突然就连不通”的疑难杂症,根源多数藏在这一段。

这篇内容最大的价值,是帮你在脑海里立起一张完整的“数据交接图”:从电脑网口到交换机,从交换机到路由器,网络包到底靠什么认路、靠谁改地址、为什么一定要有 MAC 地址表和 ARP。适合正在啃网络基础、想转行做运维或网络工程师的朋友,也适合只想搞清楚“公司里两台电脑为什么互相 ping 不通”的普通开发者。

1. 先给整套框架定位:第三期究竟在讲哪一段

1.1 一条主线串起五段链路

《网络是怎样连接的》这本书厉害的地方,在于它不是按 OSI 七层模型讲,而是按“一次真实访问的完整路径”来串。我把它的核心框架拆成五段:浏览器发请求、协议栈与网卡封装、局域网转发、路由与接入网、互联网骨干与服务器响应。

前两期已经覆盖前两段。这一期是第三段:网络包变成电信号后,在网线、交换机、集线器里是怎么走的。再往后,路由器如何把包送出去,其实是第四段的内容,但网关和默认路由这两件事必须在这一期先讲清楚,不然你看到“路由表”三个字会直接卡住。

为什么这样分段对入门者最友好?因为大多数人的困惑,不在于 TCP 三次握手,而在于“数据明明已经到了本地网络,凭什么从右边电脑送到左边电脑”——这个“凭什么”就是交换机的 MAC 地址表,以及主机判断“目标在不在本地”的网段计算。框架一旦立住,后续学路由协议、防火墙策略都会顺手很多。

1.2 本期的核心问题:从“会配 IP”到“知道帧去哪了”

我接触过的初学者,大部分能背出 IP 地址、子网掩码、网关这“网络配置三件套”,但真问他“网关到底干活的”,他说不清楚。第三期就是来解决这件事的。

你可以把这一篇的目标压缩成三个问题:

  • 交换机把一个帧从 1 口转出去,依据是什么?
  • 电脑要访问另一台电脑,凭什么决定“直接发”还是“先发给网关”?
  • 帧到了路由器之后,MAC 地址和 IP 地址各自发生了什么变化?

这三个问题弄明白,你再看任何二层交换设备、任何抓包工具里的数据,都不会再觉得是乱码。后面章节的所有配合,也都是围绕这三个问题展开。

2. 交换机:局域网里的智能分拣员

2.1 MAC 地址表不是天生的,是“学”出来的

很多人以为交换机像老式电话总机,管理员手动把每个端口对应的机器填好,然后照着表去接。实际不是。普通交换机完全靠自动学习,核心就一张表——MAC 地址表。这张表记录“哪个 MAC 地址、从哪个端口能到达、学到的 VLAN 是多少、表项多久后过期”。

它的学习过程非常朴素:交换机收到一个以太网帧,先看帧头里的源 MAC 地址,记录“这个源 MAC 是从哪个端口进来的”,写进表里;再看目的 MAC 地址,去表里查该往哪个端口发。查到了就单播转发,查不到就把帧从除了接收端口以外的所有端口复制出去,这个动作叫“泛洪”。

举个例子。假设 PC-A 插在交换机的第 1 口,PC-B 插在第 2 口。PC-A 第一次给 PC-B 发包时,交换机不知道 PC-B 在哪,于是把帧复制给 2 口、3 口、4 口…… PC-B 收到后回复,交换机从第 2 口收到 PC-B 的帧,立刻把 PC-B 和端口 2 记进表里。从这以后,PC-A 再给 PC-B 发数据,交换机直接查表从 2 口出去,不再喊所有端口听一遍。

这就是“自学习”的本质。所以你在网管型交换机上执行查看 MAC 地址表的命令时,看到的表项不是厂商预设的,而是设备运行之后一点点学出来的。这个表还有老化时间,主流设备默认 300 秒左右。也就是说,一个设备如果 5 分钟没发任何帧,它的表项会被删掉,下次通信又要重新泛洪一次。这也是为什么有些低频设备(比如网络摄像头)第一次 ping 会超时,第二次才通——你还以为网络不稳定,其实是表项老化而已。

实务上有一个常用技巧:遇到“第一次不通、第二次通”的诡异现象,优先怀疑 MAC 地址表老化,而不是线路丢包。

2.2 广播、泛洪与环路隐患

泛洪是交换机处理“未知目的帧”的方式,但还有一种帧会让交换机“不得不”把数据发给所有端口——广播帧。

以太网广播帧的目的 MAC 地址写的是FF-FF-FF-FF-FF-FF。交换机只要看到这个全 F 地址,就知道这是广播,必须从除了接收端口之外的所有端口转发出去。网络里每个人都收,但不是每个人都处理——网卡收到广播帧,会看一眼目的 MAC 是自己、广播还是组播,都不是就丢弃,不会影响应用层。

泛洪和广播的区别要分清:泛洪是交换机查表查不到时才做;广播是目的 MAC 本身就是广播地址,没有办法定向。两者都会让帧传遍整个广播域。如果你的局域网里某一台机器中了病或者配置错误,疯狂发广播帧,整个二层网络都会被拖慢,这就是经常听到的“广播风暴”。

更麻烦的是环路。两根网线把交换机接到一起,又没有启用环路保护协议时,广播帧就会在两个交换机之间来回复制转发,最终把端口流量打到满。这时候你去看交换机,所有端口指示灯都在快速闪烁,仿佛整个网络疯了。排查最早出现广播风暴的根源,永远先断开可疑连接、再启用环路保护协议(比如常见的生成树协议)。这些内容在书里也有讲到,但如果你没实操过,很难体会那种“整个楼层集体断网”的紧张感。

2.3 集线器和交换机:差一个“脑子”,差出整个时代

前面用了不少篇幅讲交换机,是因为现在你几乎接触不到纯集线器了。但明白集线器为什么会死,你才懂交换机到底强在哪。

集线器是物理层设备,没有 MAC 地址表,它做的事情就是“收到什么信号,就从所有其他端口原样发出去”。这相当于一个共用的大喇叭:A 对 B 说话,C 和 D 也都能听见,只是 C、D 网卡不接收而已。更重要的是,集线器所有端口共享同一条通信链路,同一时刻只能有一个设备发送数据。假如两台电脑同时发,信号在线上撞在一起,就叫冲突。以太网早期的防冲突机制叫 CSMA/CD:先听后说,发的时候还要监听,一旦发现冲突,所有设备随机退避一段时间再重发。

这种机制下,设备越多,冲突概率越大,实际可用带宽大打折扣。交换机则完全不同:每个端口独立处理帧,端口之间可以同时通信,而且是全双工,即收和发同时进行。从“共享带宽”变成“独享带宽”,从“半双工”变成“全双工”,这就是一个“脑子”(MAC 地址表)带来的代差。

排障的时候这个知识非常管用。如果交换机端口出现大量冲突错误计数、CRC 错误,十有八九是链路两端双工模式协商失败,一端跑全双工、一端跑半双工,数据就会频繁丢失。这类问题不会直接显示“网络断开”,而是表现为“能通但很卡、丢包严重”。

3. 路由器与网关:真正决定方向的岔路口

3.1 主机先判断:目标到底在不在本地

网络包在局域网内部走得再溜,也终归要面对一个现实:目标电脑不在这个网段里。这时就该路由器登场了。但有个细节很多人没意识到——发起请求的电脑,得先自己判断“目标到底在不在本地网络”。

判断方法很简单:拿自己的 IP 和子网掩码做与运算,得到自己的网段;再拿目标 IP 和同一个子网掩码做与运算,得到目标网段。如果两个网段相同,目标就在本地,直接通过 ARP 查目标 IP 对应的 MAC 地址,把帧发给它;如果不同,说明目标在外面,主机就把帧的“目的 MAC 地址”填成网关接口的 MAC 地址,而“目的 IP 地址”仍然填目标机器的 IP。

这是全篇文章里最值得反复读的一段话。因为很多人问“我的电脑为什么把数据先发给路由器,而不是直接发给外网”,答案就在这儿:二层帧只能在同一个局域网里传播,不同网段之间的数据必须由路由器这个三层设备接力。

你可以想象一栋办公楼:同一层楼里传文件,你可以直接走过去;要寄快递到别的城市,你肯定先把东西交给楼下的快递站,由快递站决定走哪条路。路由器就是那个快递站,网关 IP 就是快递站的门牌号。

3.2 ARP:把 IP 翻译成 MAC 的那张名片

刚才提到“通过 ARP 查 MAC 地址”。ARP 的全称是地址解析协议,作用就是根据 IP 地址找到对应设备的 MAC 地址。它的工作过程像在走廊里大喊一声:“谁是 192.168.1.10?请把你的 MAC 告诉我。”

这一步用的是广播帧:源主机把 ARP 请求包封装在一个目的 MAC 为FF-FF-FF-FF-FF-FF的广播帧里发出去。局域网内所有设备都会收到,但只有 IP 地址匹配的那台机器才会回复一个 ARP 应答,应答通常用单播帧直接发回给请求者。请求方收到后,会把 IP 和 MAC 的对应关系记进 ARP 缓存表,方便下次直接用。

Windows 上查看 ARP 缓存的命令是arp -a,Linux 上可以用ip neigh show。排障时这个命令价值极高。我见过不少情况:电脑明明配好了 IP 和网关,ping 网关却不通,一看 ARP 表,网关 IP 对应的 MAC 地址根本不是路由器应有的 MAC——这是有人手动填错了,或者局域网里出现了“争抢网关 IP”的设备。清掉缓存、重新解析一遍,问题立刻暴露。

注意,ARP 是局域网协议,路由器会把 ARP 请求限制在自己接口所在的网段内,不会替你转发到外网。所以“跨网段通信靠 IP+ 路由”,这句话永远是第一原则。

3.3 为什么 IP 和 MAC 必须成对出现

把 IP 和 MAC 的关系彻底想透,是读懂后续所有网络内容的分水岭。很多初学者会问:既然 IP 地址在全球唯一,为什么不直接用 IP 定位设备,还要弄一个 MAC 地址?

我给一个比喻:IP 地址是“人的身份证号”,MAC 地址是“你当前住的房间号”。身份证号跟着人走,但你搬了家、换了网络环境,房间号就会变。以太网帧要在同一段物理链路里被设备接收,就必须写清楚“具体哪个房间”的地址,也就是 MAC;而跨网络寻址必须靠逻辑上的“身份证号”,也就是 IP。

更准确地说,MAC 地址每次经过路由器都会被改写。主机发给网关的帧,源 MAC 是主机自己的,目的 MAC 是网关的;网关查路由表后,从一个出口转发出去时,会把源 MAC 改成出口接口的 MAC,目的 MAC 改成下一跳设备的 MAC。但整个过程中,源 IP 和目的 IP 一般保持不变。这个“MAC 一跳一跳变,IP 始终不变”的规律,就是整个互联网转发的基础。

用抓包软件看数据,最能验证这一点:同一段网络通信里,只看 IP 头,数据包的“出发地”和“目的地”始终是你熟悉的那两个地址;往下看以太网层,每一跳的 MAC 都在换。很多安全分析、故障排查,就是靠追踪 MAC 变化来定位设备位置。

3.4 默认路由:一个“0.0.0.0/0”走天下

电脑知道“目标不在本地,就交给网关”之后,剩下的路就全交给路由器的路由表了。路由表本质上是一张“告诉路由器去哪个网段该走哪个接口/下一跳”的表。

路由器处理数据包时,会拿目的 IP 对照路由表,按“最长前缀匹配”原则选择一条最精确的路径。比如目的 IP 是 192.168.2.100,同时存在 192.168.2.0/24 和 0.0.0.0/0 两条路由,路由器会优先选掩码更长的 /24 条目,而不是默认路由。

这里的 0.0.0.0/0 就是默认路由,它表示“所有没写过更明确走向的地址,都从这里走”。你平时在电脑上配置“默认网关”,本质就是给这台主机添加一条 0.0.0.0/0 的默认路由。

这一期先理解到“默认路由=所有未知流量的大门口”就够用了。真正的动态路由协议(比如自动交换最优路径的那些协议)到第四期再展开,因为那时我们才进入多家运营商、多层路由表互相交换的世界。现在你只要记住:没有默认路由的内网主机,离开本网段的所有通信都会失败。

4. 最小实验:把“转发”从纸上搬到屏幕

4.1 实验拓扑与观察点

理论讲再多,不如自己动手抓一个包。这个实验只需要两台电脑、一台傻瓜交换机、一个家用路由器(当网关用),再加一个可以装抓包工具的笔记本,就够了。

拓扑建议搭成这样:PC-A 和 PC-B 都接在交换机上,路由器的 LAN 口也接同一台交换机,然后把 PC-A 当作主要观察对象,用 Wireshark 抓它的流量。IP 规划就按最常见的网段来,例如 PC-A 是 192.168.1.10,PC-B 是 192.168.1.20,路由器 LAN 口是 192.168.1.1,掩码统一 /24。记住 PC-A 和 PC-B 的默认网关都要填 192.168.1.1。

这个实验的目标是回答三个问题:同网段互访时,帧目的 MAC 到底是谁;跨网段访问时,帧目的 MAC 会不会变成网关;交换机在中间到底做了什么。

4.2 抓包实战:同网段和跨网段的帧差别很大

先让 PC-A ping PC-B。开始前在 PC-A 上开好 Wireshark,抓包之后观察,你会先看到一个 ARP 广播请求,紧接着是 PC-B 的 ARP 应答。再往后才是 ICMP 的 Echo Request 报文。

这时候看以太网层的“Destination MAC”一栏,会发现它填的是 PC-B 的 MAC 地址,而不是网关的 MAC;再看 IP 层的“Destination IP”,同样填的是 PC-B 的 IP。这说明什么?同一网段,主机判断目标在本地,所以把目的 MAC 和目的 IP 都指向目标机器。

接下来让 PC-A ping 一个外网地址(也可以直接用电脑里配置的模拟公网网段,比如另一个网段的测试 IP)。关键操作前先执行清 ARP 缓存的命令,保证整个过程可以被完整观察到。再抓包时就非常清楚了:ICMP 请求的 IP 层,目的 IP 是外网目标;以太网层,目的 MAC 却是路由器的 LAN 口 MAC。这就是“IP 不变、MAC 变下一跳”的直观证据。

4.3 用镜像端口看交换机眼中的世界

直接在 PC-A 上抓包,只能看到 A 自己收发的内容。如果你想看交换机在中间到底做了多少次泛洪,就得用带有端口镜像功能的网管型交换机。把笔记本接到交换机的镜像口上,然后把 PC-A 的端口配置成源端口,这样笔记本就能复制一份流过该端口的所有帧。

重启实验前,先清空交换机的 MAC 地址表(通常重启即可)。让 PC-A ping PC-B,你会在镜像端口上看到非常有意思的现象:第一次通信时,交换机确实把帧泛洪到了很多端口,同时能数出 ARP、ICMP 等不同类型的帧。第二次再 ping,捕获到的帧数量明显变少,因为 MAC 表已经建立,不再需要全网广播。这个过程能把“自学习”从概念变成肉眼可见的事实。

很多朋友做实验没有镜像口,也可以接受。只要明白一个原则:抓包不等于看到交换机的全部转发行为,抓包只能告诉你本机收发了什么。要验证交换机的转发决策,还是要看设备的 MAC 地址表和统计计数。

4.4 把验证结论变成一套排查动作

做完实验,可以顺手把自己的排障步骤固化成一套动作:先确认本机 IP 和掩码,判断目标网段;再查 ARP 缓存,看目标 IP 对应的 MAC 是否合理;接着 ping 网关,把问题范围切成“本端”和“外部”;最后才考虑交换机端口状态、VLAN 和路由表。这个顺序能避免你一开始就往复杂的路由协议里钻。

这也是我推荐每个人都做一遍这个最小实验的原因。光学知识点,你虽然知道交换机有 MAC 表,但不知道表会老化、广播会泛洪。踩过“第一次不通、第二次通”的坑之后,再看到这类报障,基本不用抓包也能猜个八九不离十。

5. 常见问题与避坑:书里没写全的那些细节

5.1 问题速查表

现象常见原因排查命令/方法
同一交换机下两台电脑互 ping 不通掩码错误、ARP 表异常、防火墙拦截核对 IP/掩码,清 ARP 缓存,关防火墙测试
能 ping 通网关,但上不了外网路由器默认路由缺失或运营商侧故障查看路由器路由表,确认 0.0.0.0/0 是否存在
第一次 ping 通,第二次通不过MAC 地址表老化、ARP 缓存过期多次 ping,观察 ARP 解析过程,确认表项老化时间
网络延迟大、丢包严重双工模式不匹配、网线质量差查看交换机端口错误计数,强制端口双工/速率
整个办公室突然断网二层环路、广播风暴逐个断开交换机级联口,启用环路保护协议
端口灯亮但数据传不动协商异常、VLAN 配置不一致查看端口状态,确认两端 VLAN 编号一致

这张表解决的是“看到现象后去哪里找原因”的问题。真正的排障高手,不是一下子猜中答案,而是能用最快速度把可能范围一次次缩小。

5.2 三个容易踩的认知坑

第一个坑:以为 MAC 地址表记录了 IP 地址。 查表时你会看到 MAC 和端口,这没问题,但它不代表交换机会关心 IP。三层以下交换机根本不去解析 IP 头,它对“192.168.1.10 属于谁”毫无概念。一定要形成条件反射——二层设备看 MAC,三层设备看 IP。

第二个坑:以为 MTU 1500 是“网络包总长”。 以太网帧的 1500 字节特指载荷部分,排头尾的 MAC 头、FCS 校验等都不算。如果你把 MTU 理解成整个帧的长度,在配置隧道、调整分片策略时就会出大问题。实际抓包里常见帧总长度在 1518 字节左右,就是因为加了以太网头部和校验。

第三个坑:以为“交换机隔离冲突域”等于“交换机隔离广播域”。 交换机确实把每个端口隔成独立冲突域,但广播域默认还是同一个。两台交换机级联在一起,二层广播帧照样会全部扩散。需要隔离广播域时,要上 VLAN 和三层路由,这个知识点会在后面几期越来越重要。

5.3 一套能直接照做的快速排查思路

无论新人还是老手,我建议把排查顺序固定下来。先物理层,看网线灯亮不亮、端口状态 up 还是 down;再二层,看交换机端口 CRC 计数、MAC 表有没有学错;然后三层,看本机 IP、网关、ARP、默认路由;最后再往上看上层服务和防火墙策略。

这套流程的好处是避免“盲猜”。我曾遇到过朋友办公室两台电脑连同一台交换机但一个能上网一个不能,他怀疑交换机坏了。我让他先ipconfig /all对比一下,结果发现不能上网那台的网关填错了网段。这就是典型的跳过了三层排查直接怀疑硬件。越是大问题,越要一层一层来,因为网络协议栈本来就是分层的,排查也应当分层。

这个“分层思维”是第三期真正想传递给大家的隐形知识。它比记住几个 MAC、ARP 关键词更值钱。


我个人带新人时,最常强调的一句话是:网络转发不是靠“感觉”,而是靠“每一层都有明确决策依据”。交换机依据 MAC 表,主机依据网段计算和 ARP,路由器依据路由表。当你能说出某个包在某台设备上依据什么转发、改了哪些地址时,你才真正跨过了网络入门那道坎。这篇第三期帮大家立起交换机和路由器这两根主梁,后面接入网、互联网骨干那些内容,都在这套框架上继续加砖。

相关新闻

滑块验证码如何识别人机?从轨迹分析到风控引擎的完整原理

滑块验证码如何识别人机?从轨迹分析到风控引擎的完整原理

1. 验证码到底在验证什么?——先搞清楚人机对抗的根源踏进这个领域之前,我曾经以为验证码就是个“防机器人”的小工具。直到自己动手从零搭过滑块、研究过轨迹采集、被风控策略折磨过之后,才意识到验证码体系的本质其实是一场关于“信任边界”…

2026/10/20 3:23:03 阅读更多 →
YOLO+AI大模型智慧农业农作物病害识别检测系统实战拆解

YOLO+AI大模型智慧农业农作物病害识别检测系统实战拆解

最近一段时间,陆续有好几个同学来问我同一个问题:毕设想做植物病害识别,题目里写着“YOLOAI大模型智慧农业农作物病害识别检测系统”,目标是“对标硕士论文”,还带源码、LW、PPT和讲解这些交付物。这东西到底该怎么做&…

2026/10/20 3:23:03 阅读更多 →
霞鹜文楷开源楷体完整指南:免费商用覆盖2万余字

霞鹜文楷开源楷体完整指南:免费商用覆盖2万余字

霞鹜文楷开源楷体完整指南:免费商用覆盖2万余字 【免费下载链接】LxgwWenKai An open-source Chinese font derived from Fontworks Klee One. 一款开源中文字体,基于 FONTWORKS 出品字体 Klee One 衍生。 项目地址: https://gitcode.com/GitHub_Tren…

2026/10/20 3:23:03 阅读更多 →

最新新闻

Pallas引擎如何看穿AI写作?从降AI到人机协同的正确路径

Pallas引擎如何看穿AI写作?从降AI到人机协同的正确路径

先说结论:2026年了,还在问“怎么降AI”的人,思路本身就反了。真正的答案不是研究怎么骗过Pallas引擎,而是研究为什么它盯上你。我把国内外主流AIGC检测工具,包括知网近期升级的Pallas引擎思路做了拆解,结合…

2026/10/20 7:14:56 阅读更多 →
Boost PFC CCM平均电流控制与相位补偿的Plecs仿真实战

Boost PFC CCM平均电流控制与相位补偿的Plecs仿真实战

做开关电源仿真绕不开PFC这个话题。最近我把Boost PFC的CCM平均电流控制叠加电流相位补偿控制,在Plecs里完整跑了一遍仿真,从主电路参数计算到控制环路搭建,再到波形分析和问题排查,整个过程踩了几个坑,也把原理重新梳…

2026/10/20 7:14:56 阅读更多 →
批量出图怎样做到像素级可控?规则渲染管线实战解析

批量出图怎样做到像素级可控?规则渲染管线实战解析

这个需求最近真的很多人问。我自己的项目里也是碰到一模一样的瓶颈:业务方要求批量出图,图片里不能有丝毫随机性——同样的输入必须产出同样的构图、同样的配色、同样的文字位置。拿通用多模态生成模型试了几轮,效果确实惊艳,但根…

2026/10/20 7:14:56 阅读更多 →
litellm:统一大模型接入层,解决多模型切换与适配之痛

litellm:统一大模型接入层,解决多模型切换与适配之痛

最近在做一个多模型调度的内部项目时,我把团队的模型接入层整体切换到了 litellm。这个决定帮我省掉了大量重复的适配代码,也让我们在评估不同大模型服务时效率高了不少。如果你同样被"每个模型一套 SDK、一套请求格式、一套报错风格"折磨过&a…

2026/10/20 7:14:56 阅读更多 →
新手考古路线图:3 步定位登月舱降落代码 BURN, BABY, BURN——从 Luminary099 源码索引到 P63 着陆算法

新手考古路线图:3 步定位登月舱降落代码 BURN, BABY, BURN——从 Luminary099 源码索引到 P63 着陆算法

新手考古路线图:3 步定位登月舱降落代码 BURN, BABY, BURN——从 Luminary099 源码索引到 P63 着陆算法 【免费下载链接】Apollo-11 Original Apollo 11 Guidance Computer (AGC) source code for the command and lunar modules. 项目地址: https://gitcode.com/…

2026/10/20 7:14:56 阅读更多 →
投机推理:突破大模型自回归瓶颈的并行验证加速技术

投机推理:突破大模型自回归瓶颈的并行验证加速技术

1. 大模型推理的“车堵一条道”困局老做推理优化的朋友都有过这种体验:GPU 明明算力爆炸强,但每次生成一个 token 都得几毫秒甚至几十毫秒,batch 稍微大一点,延时就像坐火箭一样往上蹿。一开始我们都骂“模型太大了”,…

2026/10/20 7:13:55 阅读更多 →

日新闻

CLRC663芯片Pin-to-Pin替代实战:从评估到量产全记录

CLRC663芯片Pin-to-Pin替代实战:从评估到量产全记录

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 1:01:30 阅读更多 →
ESP32舵机控制指南:原理、多路驱动与避坑实战

ESP32舵机控制指南:原理、多路驱动与避坑实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 1:01:30 阅读更多 →
位移法实现一阶低通滤波:单片机ADC采样降噪实战

位移法实现一阶低通滤波:单片机ADC采样降噪实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 1:01:30 阅读更多 →

周新闻

基于GMM的语音识别系统原理与MATLAB实现详解

基于GMM的语音识别系统原理与MATLAB实现详解

说到基于高斯混合模型(GMM)的语音识别系统,很多人第一反应就是一堆数学公式,觉得门槛很高。但如果你真的在MATLAB里把它落地跑通,会发现核心其实就是三件事:把声音变成特征向量,用GMM给每个类别…

2026/10/19 10:02:04 阅读更多 →
数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理这四个字听起来挺唬人,但落到具体操作上,无非就是让计算机按你的想法“摆弄”像素。我在一个模拟项目X里用了一套特别经典的基础处理流程:对图像做反白、改调色板、彩色转灰度,最后把像素数据导出成txt文件。单看每一…

2026/10/19 17:32:41 阅读更多 →
机器人大脑技术盘点:具身智能的感知、决策与数据闭环

机器人大脑技术盘点:具身智能的感知、决策与数据闭环

如果你的信息流最近也天天刷到“机器人大脑”这个词,你会发现一个很有意思的现象:每个人说的“大脑”根本不是同一个东西。有人指的是大语言模型,有人指的是运动控制系统,还有人指的是能理解物理世界的端到端模型。在2026年这个时…

2026/10/20 2:50:50 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/19 2:54:50 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/19 9:10:22 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/18 12:16:16 阅读更多 →