交换机工作原理详解：MAC地址表、转发与排障实战-北京尧图网络

这周的日志我不打算继续记新协议而是想把交换机的原理从头到尾捋一遍。原因很简单不管做网络运维还是准备认证考试交换机都是绕不开的基础设备。你在办公室、机房、家里看到的那些带一排网口的盒子大多数都是交换机它负责把电脑、服务器、摄像头、无线AP连进同一张局域网。很多人天天在用交换机但真被问到“一个数据帧进来它怎么知道该从哪个口出去”一下子就讲不清了。这篇日志适合正在啃网络基础的同学、刚入行的运维新人也适合想把自己手边普通设备玩明白的人。我会把MAC地址表、二层转发、泛洪、广播域这些概念拆开讲再用模拟器实验从头验证一遍最后附上日常排障中一定会用到的经验。1. 先搞清楚交换机在网络里到底干了什么活1.1 交换机到底是什么从群聊室到电话总机想理解交换机先看它的前辈集线器。集线器是个纯粹的物理层设备一个端口收到电信号就向所有端口广播出去所有接在集线器上的设备等于挤在同一个“群聊室”里。同一时刻只能有一个人发言要是两个人同时开口信号就撞车了大家都要退避重说这就是冲突域的概念。带宽也是共享的一个百兆集线器接了四台电脑理想情况下每台只能分到25兆实际因为冲突重传效率更低。交换机不一样它工作在OSI模型的第二层也就是数据链路层转发的基本单位是数据帧。它看起来和集线器长得像但内部逻辑完全不同每个端口到交换机背板都有自己的独享通道两台设备通信时其他端口不受影响可以同时有多对设备并行收发数据。形象点说交换机更像“电话总机接线员”它知道每个分机在哪条线路上谁要联系谁就直接把线路接通而不是对着整栋楼喊话。为什么交换机能做到这一点核心在于它会“记路”。它把每个端口下连着哪台设备的网卡地址记下来以后有数据要送直接送到对应端口而不是无脑广播。这张记录地址和端口对应关系的表就是后面要重点讲的MAC地址表。1.2 交换机的三个基本动作学习、转发、隔离冲突把交换机的工作拆开看本质上就三个动作。第一是学习。交换机从某个端口收到一个帧会把帧里的源MAC地址记下来形成“这个MAC在这个端口”的对应关系写进MAC地址表。这个学习是被动的只要有流量经过它就会自动记录不需要人工干预。第二是转发或过滤。交换机收到帧后提取目的MAC地址去MAC地址表里查。查到了就知道该从哪个端口发出去这叫精确转发查不到就向除接收端口以外的所有端口转发让“失主”来认领这个动作叫泛洪。如果目的MAC和源MAC在同一个端口那说明接收者和目的地都在一条链路上交换机直接丢弃这个帧不需要转发这叫过滤。第三是隔离冲突。每个交换机端口都自成冲突域端口上的设备可以全双工收发一头发一头发互不干扰。所以交换机每一跳都在消除冲突网络规模可以铺得很大而不至于像集线器那样一忙就瘫。1.3 为什么网络里既要有交换机也要有路由器交换机再聪明也只在局域网里打转。它处理的是二层的MAC地址根本不管IP地址和网段划分。当一台设备要访问另一个网段的服务器时光靠交换机是不行的因为MAC地址只能在同一个广播域内寻址跨网段必须由路由器来转发。打个比方交换机是楼内的快递分拣员知道每层每户的门牌号能把包裹送到本楼任意一家路由器是城市间的快递干线负责把包裹从一个城市送到另一个城市进入对方城市后再由当地的交换机分拣。所以一个典型的企业网络里交换机负责接入和汇聚路由器负责不同网段之间的通路各司其职。设备工作层级转发依据隔离冲突域隔离广播域集线器物理层电信号否否二层交换机数据链路层MAC地址是否路由器网络层IP地址是是这个表格是面试和考证的高频考点理解了就不需要死背。2. MAC地址表交换机的核心“记忆”2.1 数据帧长什么样交换机在看什么交换机能“认识”设备靠的是网卡上的MAC地址也叫物理地址。这个地址出厂时烧录进网卡理论上全球唯一用十二个十六进制字符表示比如00:1a:2b:3c:4d:5e。在局域网里MAC地址就是最精确的门牌号。以太网数据帧的基本格式也不复杂最常接触的Ethernet II帧由这几部分组成目的MAC地址占6个字节源MAC地址占6个字节类型字段占2个字节后面是数据部分最短46字节最长1500字节最后还有4字节的帧校验序列FCS用于验证数据在传输过程中有没有损坏。交换机最关心的就是前面的12个字节也就是目的MAC和源MAC。收到一个帧它会先做两件事第一用FCS做循环冗余校验校验不过就直接丢帧坏帧不会参与转发第二读目的MAC和源MAC源MAC用于学习目的MAC用于查表决策。这里有个反直觉的地方为什么不直接用IP地址因为二层转发根本不看IP。IP地址是逻辑地址用于跨网络的路径选择MAC地址是物理地址用于同一条链路上端点到点的交付。就像快递单上的收件地址可以变但小区里的具体楼栋门牌号才是最终送到门口的依据。2.2 MAC地址学习的完整过程接收、记录、老化MAC地址学习的过程可以用三步概括接收、记录、老化。交换机从某个端口收到一个帧首先提取源MAC地址检查MAC地址表里有没有这个记录。如果没有就新建一条表项内容是“源MAC地址接收端口所属VLAN 老化剩余时间”如果已经有这条记录就刷新它的时间戳说明这个设备依然活跃在对应端口下。老化时间默认一般是300秒。也就是说如果一台设备在5分钟内没有任何帧从该端口发出交换机会把它的MAC表项清掉。这个机制非常关键设备关机、搬走、换口之后表项不会永远残留旧记录被清理后交换机就能重新学习正确的位置。如果表项永不老化网络拓扑一变化交换机还会按照旧记录转发数据就送错地方了。为什么学习的是源MAC而不是目的MAC这个疑问我当初也纠结过。原因不复杂帧从某个端口进来目的MAC对应的设备在哪里咱们还不知道但源MAC一定是从这个端口进来的这是唯一能确定的信息所以先记源地址。等到目标设备回包时它的MAC又会作为源MAC被学习一次这样来回几个包双方的MAC表项就都齐了。所谓“先记源后找目的”就是这个逻辑。2.3 转发决策三选一单播转发、泛洪、丢弃MAC地址表学完之后真正干活的时候是转发。交换机拿到一个帧查目的MAC一般会命中三种情况。第一种是已知单播转发。目的MAC在MAC表里有记录交换机直接把帧从对应端口发出去其他端口不受影响。这是最高效的路径也是交换机性能的核心价值。第二种是未知单播泛洪。目的MAC在MAC表里查不到交换机不知道目标设备在那个端口只好把帧复制一份从除接收端口以外的所有端口发出去让目标设备自己“回话”。回到前面电话总机的比喻就是总机暂时不知道分机位置只能挨个线路问一遍。第三种是广播和组播处理。目的MAC是全FF:FF:FF:FF:FF:FF的广播帧交换机必须泛洪到所有端口因为广播本身就是发给所有人的组播帧则会结合组播侦听机制决定是泛洪还是精确转发。很多人一听到“泛洪”就紧张以为是什么攻击行为。其实泛洪只是交换机在缺少信息时的兜底方案就像你在陌生小区找一家没去过的人家只能挨家按门铃。代价是消耗带宽所以泛洪过多时网络会明显变慢后面故障排查部分会再聊。2.4 一个简单的ping包隐藏了整个流程纸上谈兵不如跑一个例子。假设PC A要ping PC B两台设备在同一台交换机下都是第一次通信。第一步PC A发现目标IP和自己同网段于是发一个ARP广播请求问“谁是这个IP请把MAC地址告诉我”。这个广播帧进入交换机目的MAC是全F交换机泛洪到所有端口。第二步PC B收到ARP请求发现问的是自己就回复一个单播ARP应答源MAC是PC B目的MAC是PC A。交换机收到这个帧一方面从源MAC学到“PC B在这个端口”另一方面根据目的MAC查表之前PC A发广播时交换机已经学过了PC A的端口所以这次能精确转发给PC A。第三步PC A拿到了PC B的MAC地址把ICMP echo request封装成帧目的MAC填PC B。交换机查表命中直接转发。后续PC B回echo reply时交换机也已经有PC A的记录了同样精确转发。所以你会观察到一种现象第一次ping的时候会有一个短暂“热身”后面就非常顺畅。这个“热身”不是ICMP本身慢而是ARP学习和MAC表建立的过程。理解了这一点再看抓包文件就一目了然了。3. 把原理跑出来模拟器实验与抓包验证3.1 实验拓扑与准备原理说一百遍不如动手跑一遍。我建议用图形化的网络模拟器来做实验这类工具能让你直接看到帧在交换机内部的事件流转也可以随时清空MAC表、重放流量现实中很难这么方便。最基础的环境是一台二层交换机下接三台PC分别命名为PC1、PC2、PC3三台PC的IP配置在同一网段比如192.168.10.1/24、192.168.10.2/24、192.168.10.3/24。交换机不做任何额外配置默认所有端口都在同一个VLAN里这正好满足了广播域的基本实验条件。如果你手头有真实的小交换机也可以做类似实验两台电脑通过普通网线接到交换机上用抓包工具抓取其中一台电脑的流量。普通傻瓜交换机一般不支持端口镜像所以想看全貌比较难但抓本机收发的帧也够验证基本原理。模拟器的优势在于你能同时看到三台机器的视角以及交换机内部MAC表的变化。3.2 观察MAC地址表的建立过程实验第一步先在交换机控制台清空MAC地址表。不同厂商命令有差异常见的一种是执行清空MAC表命令再查看确认表为空。如果是新启动的设备表本来就是空的但为了实验严谨最好手动清一次。实验第二步让PC1 ping PC2。只ping一次就够了不用一直ping。实验第三步回到交换机控制台输入查看MAC地址表的命令比如某类设备风格是display mac-address另一类风格是show mac address-table根据你用的模拟器选择即可。命令敲下去你会看到类似这样的表项MAC Address VLAN Port Type 00:aa:bb:cc:00:01 1 GE0/0/1 dynamic 00:aa:bb:cc:00:02 1 GE0/0/2 dynamicPC1和PC2的MAC地址分别被学习到了GE0/0/1和GE0/0/2端口上。这里需要注意的是PC3的MAC地址可能也会出现在表里因为你刚才打开模拟器的时候PC3可能已经自发发送过一些广播报文比如开机时的DHCP请求或者地址解析报文。只要源MAC出现过交换机就会学习这种“被动学习”的行为在真实网络里时刻都在发生。3.3 用抓包验证“第一次泛洪和后续单播”为了看清泛洪和精确转发的区别可以在模拟器的仿真模式下观察帧的流转或者直接在PC上抓包。仿真模式会把网络里的每个数据包按事件列表展示出来交换机对帧的处理动作都写得很清楚对于学习原理特别有帮助。你会在事件列表里看到两类典型的帧第一类是ARP广播请求目的MAC为全F。交换机的处理动作是“泛洪”它会把这个帧发送到除接收端口外的所有端口。这也是为什么PC3明明没参与这次ping但它也会收到这个ARP广播只是它不回应而已。第二类是ICMP echo request和echo reply这些帧的目的MAC都是具体的单播MAC地址。交换机的处理动作是精确转发只会从对应端口出去PC3不会收到这些帧。这里有个常见的误区要纠正很多人以为ping包是“广播”出去的其实完全是误解。真正广播出去的只有最开始的ARP请求一旦双方MAC地址都学习到了后续所有的数据帧都是单播精确转发。搞清楚这一点网络的“带宽明明不大却总能正常工作”就好理解了因为单播数据并没有打扰到所有人。3.4 实验之外的补充静态MAC表项动态学习足够日常使用但有些场景需要手工配置静态MAC表项。静态表项的作用是把某个MAC地址固定绑定到某个端口不再依赖动态学习这样可以防止设备私自更换接入端口也能避免服务器MAC漂移导致的转发异常。配置静态表项时可以把服务器的MAC地址和固定接入端口绑在一起并配上所属VLAN。需要注意配置了静态表项之后交换机就不会再动态学习该MAC了如果设备真的换了端口反向流量就会发不出去直到你手工修改表项。这个特性适合用在服务器、打印机这类位置固定的设备上不太适合用在人员流动性大的办公网。4. 从广播域到VLAN交换机如何隔离网络4.1 广播域太大会发生什么一台二层交换机默认把所有端口放在同一个广播域里实际默认VLAN是VLAN 1所有设备都听得见彼此的广播帧。这在设备少的时候没问题但设备一多广播域太大就会出问题。想象一下几百人和你挤在同一间大办公室里只要一个人喊一声“谁看见我的钥匙了”所有人都要停下来听一听哪怕这事跟自己毫无关系。网络里也一样ARP请求、DHCP发现、各种协议的心跳报文都是广播帧交换机必须把它们泛洪到广播域内所有端口。广播越多每台设备的CPU和网络带宽被消耗得越厉害真正有用的数据反而被挤到一边。广播域过大的另一个坏处是排障难。一个部门出了故障广播报文会传到另一个部门两边网络状态互相干扰。这时候把网络划分成多个VLAN就是给网络装上一道道隔音墙让每个小团队在各自的房间里沟通。4.2 VLAN标签与Access、Trunk端口VLAN虚拟局域网是二层网络里最核心的概念。它的实现原理是给以太网帧头部插入一个标签用4字节的VLAN Tag告诉交换机这个帧属于哪个VLAN。标签里最关键的字段是12位的VLAN ID取值范围1到40940和4095有特殊用途。交换机端口根据角色分成两类Access口是接入端口默认只处理一个VLAN。连接终端设备时帧从终端进入交换机交换机给它打上该端口所属VLAN的标签帧从交换机发给终端时会把标签剥掉终端看到的还是普通以太网帧。这样终端根本感知不到VLAN的存在接入起来很简单。Trunk口是干道端口用于交换机之间互联可以同时承载多个VLAN的流量。帧在Trunk链路上是带着VLAN标签走的这样另一台交换机才能区分这个帧属于哪个VLAN。配置Trunk口有两个容易踩的坑一是Trunk不会自动放行所有VLAN必须显式允许需要通过的VLAN二是要特别注意Native VLAN本征VLANTrunk链路上不带标签的流量默认属于这个VLANTrunk两端的本征VLAN必须一致否则帧会被错误地归到不同的VLAN里形成很隐蔽的通信故障。4.3 VLAN间的通信一定需要三层划了VLAN之后不同VLAN之间默认是互相隔离的二层帧出不了VLAN的边界。如果老板要求财务部能访问研发部的服务器那就必须引入三层转发。最常见的方式是用支持三层功能的多层交换设备给每个VLAN创建一个VLANIF逻辑接口相当于给这个VLAN配一个IP地址作为网关。比如VLAN 10的设备网段是192.168.10.0/24网关就是192.168.10.1配置在VLANIF 10上VLAN 20的设备网段是192.168.20.0/24网关是192.168.20.1配置在VLANIF 20上。设备访问其他网段时把帧发给自己的网关三层设备根据路由表把帧转发到目标VLAN的网关再二次封装后送到目标设备。或者也可以用路由器配合交换机做单臂路由但生产环境里还是三层交换机更高效因为路由转发由硬件完成性能好得多。理解了VLAN和VLANIF的关系你就明白了很多园区网络里动不动就几十个VLAN背后的原因——每个部门、每个业务类型、每类终端都会规划一个独立网段互不干扰又可以通过三层策略灵活互通。5. 交换机最怕的环路广播风暴与STP5.1 环路是怎么形成的后果多严重交换机可以提供冗余链路来增加可靠性但如果配置不当冗余链路会变成要命的环路。最常见的环路来源就几种一根网线插回同台交换机造成自环两台交换机之间接了两条线做“备份”却没启用生成树协议或者某个用户私自接了一台小交换机两边又各自上联导致成环。环路为什么会那么可怕想象一个广播帧进入交换机后找不到出口被泛洪到所有端口其中一条链路又把帧送回了另一台交换机这台交换机再次泛洪帧又绕回来。这个过程不断重复广播帧像滚雪球一样越滚越多很快把链路带宽全部占满交换机CPU也大量耗费在处理这些重复帧上。这就是广播风暴。环路还会导致MAC地址表震荡。同一个MAC地址一会儿从端口A学到一会儿从端口B学到交换机不断删除和重建表项二层转发决策完全乱套。此时网络的表现就是全线瘫痪连基本的访问都卡到无法忍受。我见过一个很典型的场景某办公室为了“增强冗余”从墙上同时拉了两根网线一左一右都插到同一台交换机上本意是断了一根还有另一根结果两根其实连到了同一个上游设备直接构成了环路。那个楼层的网络从早上开始就一卡一卡到最后彻底连不上拔掉一根线后立刻恢复。所以看到这种“一根线不够我再插一根”的操作一定要先弄清楚物理路径再决定加不加冗余。5.2 STP/RSTP阻塞端口打破环路为了解决环路问题必须有个机制能在物理存在环路的拓扑里逻辑上断开环路。这就是生成树协议STP要做的事。STP的核心思想是让交换机之间交换一种叫BPDU的协议报文通过比较优先级和MAC地址选出一台交换机作为根桥然后每台非根桥计算自己到根桥的最短路径选出根端口和指定端口其他冗余端口就进入阻塞状态不再转发普通数据帧只监听BPDU。这样从根桥出发到每个节点都只有一条逻辑通路环路物理上还存在但数据不会绕圈了。端口状态在STP里会经历阻塞、监听、学习、转发几个阶段这个过程需要几十秒所以老STP在拓扑变化后恢复会比较慢。RSTP快速生成树改进了状态机和握手机制收敛时间可以缩短到秒级现在网络设备基本都默认运行RSTP或者更进阶的MSTP。做排障时遇到链路切换后业务中断半分钟的情况多半就是STP收敛时间在发挥作用检查一下是不是还有老版本的STP在跑。5.3 一次真实的环路排查过程有一回某分公司反映整个办公网变得异常卡顿核心交换机CPU占用率接近百分之百。我登上去查看端口流量统计发现有两个端口收发的数据速率都顶着物理上限而且一直在跳不像是正常业务流量。再查MAC地址表发现同一台设备的MAC在多个端口之间反复出现这基本可以断定是环路。排查思路是先用“拔线法”缩小范围。我把两个可疑端口对应的网线逐一拔掉拔到某根线时核心交换机CPU占用立刻降下来全网恢复正常。重新插回那根线故障立即复现。顺着那根线去找另一端发现它接回了另一台交换机而那台交换机又有一条上联线回核心正好构成了环。至于为什么没被STP阻断原因是其中一台傻瓜交换机根本不参与STP也不转发BPDU上游设备默认链路无环就这么一路放行到瘫痪。这次排查给我的经验是环路拓扑往往不是故意设计的而是被线缆混乱拖下水的。给线缆做规范标签、梳理物理连接和配置STP同样重要。排查时不要只看设备状态先看物理拓扑再逐层查逻辑配置效率会高得多。6. 常见问题与排查技巧实录6.1 设备插上端口却拿不到IP网络排障里最常见的一个问题就是电脑插到交换机端口上网卡显示已连接但一直拿不到IP地址。按照OSI层次从下往上排查通常最有效。先看物理层交换机端口指示灯亮不亮网卡协商速率是百兆还是千兆。再看数据链路层确认端口所属VLAN是否和终端应该在的网段一致以及端口是否出于STP阻塞状态。STP刚启动时端口要经过监听和学习阶段这期间电脑拿不到IP是正常的等几秒就好。如果端口配置了端口安全或MAC地址绑定也要检查是不是因为终端MAC不在允许列表里导致交换机拒绝转发数据。有些设备的端口默认启用了DHCP snooping非信任端口的DHCP报文会被丢弃这时候终端拿不到地址不能直接怪DHCP服务器。这类问题先看交换机日志和端口计数往往能找到真实原因。6.2 MAC地址漂移的隐蔽原因MAC地址漂移是指同一个MAC地址在多个端口之间被交换机反复学习。除了环路还有两个隐蔽的场景容易被忽略。第一是用户私接小交换机或家用路由器。有些用户会把一个小交换机接在办公网端口上再把几台设备都挂上去如果这个小交换机又有两个口同时上联到办公网就会形成一个物理环路MAC漂移告警随之而来。第二是网卡负载均衡或虚拟化主机的多网卡绑定。服务器上做了多网卡负载均衡或者虚拟机迁移后同一个虚拟MAC可能在多个物理端口上切换交换机会频繁刷新表项看起来很像漂移。生产环境里遇到这种告警先确认是否有合法的服务器多网卡绑定再判断是不是恶意私接设备。很多网络设备能把漂移告警记录到日志里并标注具体端口结合日志定位是最快的。6.3 端口协商失败与线缆问题另外一个让运维头疼的问题就是端口速率和双工模式协商异常。设备互联时两端应该自动协商成相同的速率和双工模式如果协商不一致比如一端是千兆全双工另一端却锁在百兆半双工就会出现大量冲突和重传表现为网速极慢、丢包严重。查这个问题的标准动作是看端口统计里的错误计数CRC错误、冲突帧、晚期冲突等。如果发现CRC错误持续增长先换根网线试试很多问题出在水晶头压线不合格或者网线老化上。五类线跑千兆困难是常态跑着跑着自动降级到百兆的情况并不少见。如果确认线缆没问题就要检查两端设备是否有厂商兼容性问题必要时把两端强制设为相同的速率和双工模式。不过强制双工要谨慎必须两端一起设置否则人为制造不匹配反而更糟。6.4 交换机CPU占用过高查什么交换机CPU和服务器CPU不太一样数据帧大部分由硬件芯片直接转发只有协议报文、控制报文和异常流量才会上CPU。所以CPU占用过高通常意味着有什么东西在大量冲击CPU。典型原因包括广播风暴、环路导致的重复帧、大量未知单播泛洪、STP拓扑频繁变化、ARP请求异常泛滥等。排查时先看CPU占用率再抓包看协议分布是ARP多还是STP多还是纯粹的广播流量大。如果单纯是广播报文多可以考虑开启端口的风暴控制设置每秒钟允许通过的广播报文数量上限超过就丢弃或者关闭端口避免一台故障设备拖垮整个网络。风暴控制这个功能在生产环境里非常实用。在核心设备上下发限速策略后即使某个接入层出现异常问题也会被限制在局部不会影响到全网的稳定性。当然这只是治标根因还得顺着异常流量来源找到元凶。7. 把原理装进脑子之后看网络故障会有什么不一样说实话学交换机原理之前我遇到网络故障基本只有三板斧重启设备、换网线、猜是运营商问题。把MAC地址表和二层转发流程彻底搞明白之后再看故障完全是另一种感觉。网络慢的时候我会先想是广播泛滥了还是发生了环路还是有设备在刷MAC表这些思路都能从原理里直接推出来。这次日志里反复提到的一个实验习惯我觉得很值得分享每次做原理实验之前先把交换机的MAC地址表清空再截一张干净的基准备份图之后跑完流量再对比哪些MAC是新出现的、哪些设备的端口发生了变化一眼就能看出来。平时排查真实网络故障时这个基准对比的方法也非常好用很多隐蔽的环路和私接问题都是这么定位出来的。交换机原理是网络技术里最扎实的基石后面学VLAN、STP、组播、甚至网络安全里的MAC攻击和防护全都建立在这套基础之上。我自己的体会是不用急着追求高大上的协议先把一台最普通的交换机“吃透”再看其他设备和技术会轻松很多。有条件的话找一台真实交换机接上几台电脑亲手跑一遍抓包和查表的流程比读十篇理论文章都管用。

交换机工作原理详解：MAC地址表、转发与排障实战

相关推荐

英语电影院口语训练：从选片、观影到复盘的完整实操方法

支付宝地推到底是干啥的?靠谱吗?月入过万真的假的?

eBPF CO-RE自动定位原理：一次编译，到处运行

更多资讯

用Terraform和Pulumi自动化云资源：ai-infra-engineer-learning中的IaC完整教程（含GitOps）

WPF中嵌入HTML编辑器：WebBrowser与C#桥接实现富文本编辑

n8n实战：用可视化节点搭建自动化工作流，告别脚本泥潭

C# WinForms工控上位机界面开发：从串口数据到自定义控件的实战方案

AI时代网站建设新标准：从传统SEO到GEO的转型实践

SpringBoot个人博客系统：Thymeleaf+MyBatis-Plus毕设实战指南

今日更新

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

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

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

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？