电路交换与分组交换:原理、延迟计算与选型指南
1. 从一个经典问题说起为什么打电话和刷网页的体验完全不同你有没有想过一个很有意思的现象同样是在网络上传输数据为什么打电话的时候声音几乎是实时连续的哪怕网络稍微抖动一下你顶多听到一点杂音但通话不会断而刷网页、看视频的时候数据是一块一块加载出来的偶尔还会转圈缓冲但哪怕中间卡了几秒恢复之后内容照样完整显示不会因为中间断了就彻底废掉。这背后其实就是两种截然不同的数据交换方式在起作用——电路交换和分组交换。这两个概念是计算机网络这门课里最基础、但也最容易被一笔带过的知识点。很多人考试能背出定义但真到了实际工作中比如做网络规划、排查延迟问题、设计实时通信方案的时候脑子里并没有一个清晰的模型去指导决策。我自己在做音视频传输和网络架构相关项目的过程中反复跟这两个概念打交道。踩过的坑包括用分组交换的思路去优化一个需要严格时序的采集系统结果抖动大得没法用也试过在带宽受限的场景下硬套电路交换的预留机制导致资源利用率低得离谱。这些经验让我意识到电路交换和分组交换不是两个死记硬背的名词而是两套根本性的资源分配哲学理解它们的差异能直接帮你判断什么场景该用什么方案。这篇文章我会从原理、实现细节、参数计算、实际选型几个维度把这两个概念彻底拆开讲清楚。不管你是刚学网络基础的学生还是已经工作几年但想把这部分知识补扎实的从业者看完之后应该能建立起一个可以直接拿来用的判断框架。2. 电路交换的核心原理与工作流程拆解2.1 电路交换到底是什么一条专属通道的建立与释放电路交换Circuit Switching的核心思想非常朴素通信之前先在发送方和接收方之间建立一条专用的物理通路这条通路在整个通信过程中被双方独占直到通信结束才释放。最典型的例子就是传统电话网络。你可以把它想象成两个人之间拉了一根专线。在通话开始之前中间的交换机需要一级一级地把这条路径上的资源比如某条链路上的一个时隙、某个频段预留出来。一旦建立成功这条路径就只属于这两个人别人用不了。通话过程中数据也就是你的声音采样后的信号沿着这条固定路径连续传输中间不需要再做任何路由决策。这个“建立—传输—释放”的三阶段模型是电路交换的灵魂。我把它拆成三个步骤来看连接建立阶段主叫方发起请求网络中的各个交换节点根据目标地址逐跳选择一条可用路径并在每一跳上预留资源。这个过程需要时间也就是我们常说的“拨号后等待接通”的那几秒。数据传输阶段路径建立后数据以连续流的形式传输。因为路径固定、资源独占所以传输延迟非常稳定几乎没有抖动。连接释放阶段通信结束后逐跳释放之前预留的资源供其他通信使用。这里有个关键点很多人会忽略电路交换预留的是“资源”不是“带宽”这么简单。在传统的时分复用TDM电话网络里每条链路被划分成很多个时隙一个通话占用其中一个固定的时隙。这个时隙不管你说话还是沉默都被你占着别人无法使用。这就是为什么电路交换的资源利用率天然偏低——沉默期也是浪费。2.2 为什么电路交换的延迟稳定但利用率低资源独占的代价电路交换最大的优点和最大的缺点其实来自同一个特性资源独占。先说优点。因为路径固定、资源独占数据从发送端到接收端的传输延迟是高度可预测的。中间没有排队等待没有路由查找没有竞争。对于语音这种对时延和抖动极其敏感的业务来说这是天然的优势。传统电话网络能做到端到端延迟稳定在几十毫秒级别靠的就是这个机制。再说缺点。资源独占意味着即使你没有数据要传这条通道也不能给别人用。我做过一个粗略的估算在典型的语音通话中双方真正说话的时间大概只占整个通话时长的40%到50%剩下的是倾听、思考、沉默。如果按电路交换的方式那50%以上的资源就被白白浪费了。在早期电话网络时代这个问题还不算致命因为业务单一大家就是打电话。但到了数据通信时代这种浪费就完全不可接受了。还有一个隐藏成本连接建立的时间开销。每次通信都要先建立路径这个建立过程在长距离、多跳的网络中可能需要几百毫秒甚至更长。对于电话来说几秒钟的接通等待可以接受但对于计算机之间的短消息交互这个开销就太大了。注意电路交换的“电路”不一定是物理上的一条独立电线在TDM/FDM系统中它是一条逻辑上的专用通道但独占性是相同的。2.3 电路交换的典型应用场景与参数计算电路交换最经典的应用就是传统语音电话网络PSTN。我们来看一个具体的参数计算帮你理解它的资源占用逻辑。假设一条中继链路的总带宽是2.048 Mbps这是典型的E1标准采用TDM划分为32个时隙每个时隙64 Kbps。其中时隙0用于同步时隙16用于信令剩下30个时隙用于语音通话。那么这条链路最多同时支持30路电话。如果每路电话的平均通话时长是5分钟每小时每路电话的平均呼叫次数是2次那么根据Erlang公式我们可以计算出在给定阻塞率下需要多少条中继。这个计算过程在实际网络规划中非常关键但这里不展开。我想强调的是电路交换的容量规划是确定性的你占用的资源是实打实的算得出来。这种确定性在语音时代是优点但在数据时代就成了枷锁。因为数据通信的突发性太强了——你可能几分钟不发一个包然后突然要传一个几兆的文件。如果为每个数据连接都预留一条专用通道那网络的资源会被瞬间耗尽。3. 分组交换的设计哲学与关键机制3.1 分组交换的核心思想把数据切碎各自找路分组交换Packet Switching的思路完全反过来了。它不预留任何资源而是把要传输的数据切成一个个小块每个小块叫做一个“分组”Packet。每个分组独立地在网络中传输经过一个个路由器最终到达目的地。这里的关键变化是资源不再被某个通信独占而是被所有通信共享。链路的带宽只有在真的有分组要传输的时候才被占用传完就释放。这就好比从“包专车”变成了“坐公交”——大家共享同一辆车谁有需求谁上车没需求就不占位置。分组交换的实现依赖于两个核心机制存储转发和统计复用。存储转发的意思是路由器收到一个分组后先把它完整地存下来检查一下有没有错误然后根据分组头里的目标地址查路由表决定从哪个端口转发出去。这个过程会引入一定的处理延迟但换来了极大的灵活性。统计复用的意思是链路的带宽根据实际到达的分组动态分配。如果某一时刻只有少量分组到达链路就只传这些分组如果大量分组同时到达就排队等待。这种“按需分配”的方式让资源利用率大幅提升但代价是可能产生排队延迟和拥塞。3.2 分组交换的延迟构成四个分量逐一拆解分组交换的延迟不是一个单一的值而是由四个部分叠加而成。理解这四个分量是排查网络延迟问题的基本功。处理延迟路由器收到分组后检查分组头、查路由表、决定转发端口所花的时间。这个时间通常在微秒级别取决于路由器的处理能力和路由表规模。排队延迟分组在路由器的输出队列中等待发送的时间。这是四个分量中最不确定的一个取决于当前的网络负载。网络空闲时排队延迟接近零网络拥塞时可能达到几十甚至几百毫秒。传输延迟把分组的所有比特推送到链路上所需的时间。计算公式是传输延迟 分组长度 / 链路带宽。比如一个1500字节12000比特的分组在100 Mbps的链路上传输延迟是12000 / 100000000 0.12毫秒。传播延迟信号在物理介质中传播所需的时间。计算公式是传播延迟 链路长度 / 传播速度。电磁波在光纤中的传播速度大约是2×10^8 m/s所以1000公里的光纤链路传播延迟大约是5毫秒。把这四个加起来就是分组从发送端到接收端的总延迟。在实际排查网络问题时我通常会先判断延迟主要来自哪个分量。如果是排队延迟占主导说明网络拥塞需要扩容或做流量调度如果是传播延迟占主导那是物理距离决定的只能通过CDN或边缘计算来缓解。3.3 分组交换的两大实现路径数据报与虚电路分组交换并不是只有一种实现方式它内部还分为两大流派数据报Datagram和虚电路Virtual Circuit。数据报方式就是每个分组独立选路。同一个消息的不同分组可能走完全不同的路径到达接收端的顺序也可能乱掉。IP网络就是典型的数据报方式。它的优点是极其灵活某条链路断了后续分组可以自动绕路缺点是无法保证顺序和延迟需要上层协议比如TCP来做重传和排序。虚电路方式则是在通信开始前先在网络中建立一条逻辑上的路径所有分组都沿着这条路径传输。注意这里的“虚”字很关键——它不像电路交换那样独占物理资源只是在路由器的转发表里记录了一条路径。分组仍然要经过存储转发仍然可能排队但路径是固定的。ATM和帧中继就是虚电路方式的代表。我个人的经验是数据报适合短消息、突发性强的业务虚电路适合长连接、需要稳定路径的业务。但现代互联网几乎全面倒向了数据报因为它的扩展性和容错性太好了。虚电路的那套机制在互联网规模爆炸之后维护成本变得不可接受。4. 两种交换方式的深度对比与选型逻辑4.1 从资源分配到延迟特性一张表看清本质差异我把电路交换和分组交换的核心差异整理成了一张表方便你快速对照对比维度电路交换分组交换资源分配通信前预留独占按需使用共享延迟特性稳定抖动小不确定可能有排队延迟带宽利用率低沉默期浪费高统计复用连接建立需要有建立延迟不需要数据报方式故障容错差路径断了就断好可动态绕路适用业务实时语音、固定速率流数据、网页、视频、突发业务计费方式按时间/距离按流量这张表里的每一行背后都有大量的工程实践支撑。比如“故障容错”这一项电路交换的路径是固定的中间任何一条链路断了通话就断了需要重新建立。而分组交换的数据报方式路由器可以自动选择备用路径对上层几乎透明。4.2 为什么互联网选择了分组交换从效率到扩展性的全面胜出互联网选择分组交换不是偶然而是多个因素共同作用的结果。首先是效率。数据通信的突发性太强了如果为每个连接预留资源网络的利用率会低到无法接受。我做过一个模拟在一个典型的办公网络中如果按电路交换的方式为每个活跃连接预留10 Mbps带宽那么一条1 Gbps的链路最多支持100个并发连接。但实际上这100个连接的平均利用率可能只有5%到10%。分组交换可以让这条链路同时支持上千个连接因为大家错峰使用。其次是扩展性。分组交换的路由器只需要维护路由表不需要维护每条连接的状态。这意味着网络的规模可以无限扩展新增节点只需要更新路由信息即可。而电路交换的交换机需要维护每条连接的状态连接数越多交换机的负担越重扩展成本呈指数级上升。最后是灵活性。分组交换可以天然支持不同速率、不同业务类型的混合传输。一个分组可以承载语音下一个分组可以承载文件数据网络不需要为每种业务单独设计。这种“一网多用”的能力是互联网能够统一通信世界的根本原因。4.3 电路交换真的过时了吗它在这些场景依然不可替代虽然互联网全面倒向了分组交换但电路交换并没有完全消失。在某些特定场景下它依然有不可替代的优势。第一是极低抖动要求的场景。比如专业音频制作中的数字音频传输某些高端设备仍然使用电路交换式的专用通道因为任何抖动都会导致音频失真。分组交换的排队延迟哪怕只有几毫秒的波动在专业音频领域都是不可接受的。第二是确定性延迟要求的工业控制场景。在一些工业自动化系统中控制指令必须在严格确定的时间内到达不能有任何不确定性。虽然现在有TSN时间敏感网络这样的技术在分组交换上模拟确定性但最底层的某些环节仍然保留了电路交换的思路。第三是资源预留明确的场景。比如某些专线服务本质上就是电路交换的思路——你付了钱这条通道就归你专用不管你有没有数据在传。这种模式在需要带宽保障的业务中仍然有市场。我的判断是电路交换不会消失但它的应用范围会越来越窄集中在那些对确定性要求极高、且愿意为此付出资源利用率代价的场景。对于绝大多数通用业务分组交换是更优解。5. 实操中的关键问题与排查技巧5.1 分组交换网络中的延迟抖动排查思路在实际运维中分组交换网络最常见的投诉就是“网络卡顿”和“延迟忽高忽低”。这通常是排队延迟在作怪。我总结了一套排查思路按顺序执行先测基线延迟用ping或类似工具测目标地址的往返延迟。如果基线延迟本身就很低比如几毫秒说明传播延迟和处理延迟正常问题大概率出在排队。再看延迟分布连续ping几百个包看延迟的分布。如果大部分包延迟很低少数包延迟很高说明存在间歇性拥塞。如果所有包延迟都高说明链路本身有问题。定位拥塞点用traceroute逐跳查看找出哪一跳的延迟突然增大。那一跳很可能就是拥塞点。检查队列配置登录到拥塞点的设备查看接口的队列长度和丢弃统计。如果队列经常满说明需要扩容或调整队列调度策略。考虑流量整形如果无法立即扩容可以通过流量整形把突发流量削峰减少排队。这套流程我在多个项目中用过基本能在半小时内定位到问题根源。关键是要有耐心一步一步排除不要一上来就怀疑最复杂的原因。5.2 电路交换仿真中的常见配置错误如果你在做电路交换的仿真或实验有几个配置错误特别常见我列出来帮你避坑时隙分配冲突在TDM仿真中如果两个通话被分配到同一个时隙会导致数据错乱。一定要确保时隙分配表是互斥的。信令通道配置错误信令通道负责建立和释放连接如果配置错了连接根本建不起来。检查信令通道的带宽和协议是否匹配。释放逻辑缺失很多仿真只实现了建立和传输忘了实现释放。结果资源一直被占用后续连接全部阻塞。阻塞率计算错误Erlang公式的输入参数是呼叫到达率和平均通话时长单位要统一。我见过有人把分钟和秒混用算出来的结果差了60倍。提示做电路交换仿真时建议先用一个最简单的两节点场景验证建立、传输、释放三个流程都正常再扩展到多节点。5.3 分组交换中的MTU与分片问题实录分组交换中有一个非常实际的问题MTU最大传输单元和分片。每个链路层技术都有自己的MTU比如以太网是1500字节。如果一个IP分组的大小超过了链路的MTU就需要分片。分片带来的问题是分片后的每个小分组都要独立传输任何一个分片丢失整个原始分组都要重传。而且分片会增加路由器的处理负担。我在实际工作中遇到过因为MTU配置不一致导致的分片问题一条路径上某些链路MTU是1500某些是1400结果大分组在1400的链路上被分片到了接收端重组时又因为某些分片丢失而失败。解决办法是路径MTU发现PMTUD发送方先发一个不分片的大包如果中间路由器发现包太大会返回一个ICMP错误消息告诉发送方应该用多大的MTU。发送方根据这个信息调整分组大小。但PMTUD依赖ICMP有些网络会屏蔽ICMP导致PMTUD失效。这时候就需要手动配置MTU或者启用TCP MSS clamping。这个坑我踩过不止一次后来养成了一个习惯在新网络环境中部署服务时第一件事就是确认端到端的MTU。可以用ping命令带不同大小的包来测试找出实际可用的最大MTU。6. 从交换方式看网络架构的演进与个人体会6.1 现代网络中的混合交换实践虽然我们习惯把电路交换和分组交换对立起来但在实际的大规模网络中两者往往是混合使用的。最典型的例子是MPLS多协议标签交换。MPLS在某种程度上借鉴了虚电路的思想它在网络边缘给分组打上标签核心路由器根据标签转发而不是查IP路由表。这大大加快了转发速度同时还能做流量工程为特定业务预留带宽。另一个例子是光网络中的波长交换。在骨干网中不同波长的光信号在同一根光纤中传输每个波长本质上就是一条电路交换式的通道。虽然上层承载的是分组数据但底层的传输仍然是电路交换的思路。这种混合架构给我的启发是没有绝对优劣的技术只有适合场景的方案。分组交换在灵活性和效率上胜出但在需要确定性保障的场景我们仍然会借用电路交换的思路。理解这两种交换方式的本质能帮你在设计网络架构时做出更明智的取舍。6.2 我踩过的坑用错交换思路的代价说一个我自己的真实教训。早期我参与过一个实时数据采集系统的设计需要从多个传感器节点持续采集数据并传到中心服务器。当时我第一反应是用分组交换的思路每个节点独立发送数据包中心服务器按到达顺序处理。结果上线后发现数据抖动非常大某些关键的控制指令因为排队延迟到达时间比预期晚了上百毫秒导致整个控制系统不稳定。后来我们重新设计借鉴了电路交换的思路为每个传感器节点在时间轴上分配固定的时隙节点只在属于自己的时隙内发送数据。这样虽然牺牲了一部分带宽利用率但换来了确定性的延迟系统立刻稳定了。这个经历让我深刻理解了一件事分组交换的统计复用优势在需要确定性延迟的场景下会变成劣势。排队延迟的不确定性是分组交换的固有特性你无法通过优化完全消除它只能通过资源预留或优先级调度来缓解。如果业务对确定性要求极高那就应该考虑电路交换式的方案而不是硬扛分组交换的缺陷。6.3 给不同阶段从业者的学习建议如果你是刚开始学网络的学生我的建议是不要只背定义要动手算一算。比如算一下一个1 MB的文件在电路交换和分组交换下分别需要多长时间传输考虑建立延迟、传播延迟、传输延迟。算过之后你对这两个概念的理解会深刻得多。如果你已经工作正在做网络规划或优化我的建议是先判断业务的延迟敏感度和突发性。延迟敏感且速率稳定的业务考虑资源预留或专线方案突发性强且能容忍一定延迟的业务用分组交换的统计复用。不要一刀切也不要盲目追求新技术。如果你在做架构设计我的建议是把交换方式的选择作为一个显式的设计决策而不是默认用分组交换。在系统设计文档里明确写出为什么选择这种交换方式它的优势和代价是什么。这样在后续排查问题时你能快速定位到是不是交换方式本身带来的限制。最后分享一个我常用的判断口诀要确定性找电路要效率找分组两者都要做混合。这个口诀不是万能的但能在你犹豫不决的时候给你一个快速的思考起点。

相关新闻

AI视频会议产品设计:全链路智能化落地与避坑指南

AI视频会议产品设计:全链路智能化落地与避坑指南

视频会议这个赛道,这两年最大的变量就是AI。我前后参与过三款视频会议产品的智能化模块设计,从最早的"语音转文字"这种单点功能,到后来尝试把AI能力铺到会前、会中、会后整条链路上,踩过的坑比想象中多得多。很多团队一…

2026/10/15 8:21:31 阅读更多 →
信息可视化设计实战:从图表选型到布局配色的系统方法论

信息可视化设计实战:从图表选型到布局配色的系统方法论

1. 从"diagram-design"这个标题能读出什么第一次看到"diagram-design"这个标题,我的直觉是:这不是一个单纯的画图工具介绍,而是一个关于"如何把复杂信息用图形讲清楚"的方法论集合。标题本身由两个词组成——d…

2026/10/15 8:20:30 阅读更多 →
15GB Docker镜像离线部署与GPU推理调优:MonkeyOCRv2内网落地全记录

15GB Docker镜像离线部署与GPU推理调优:MonkeyOCRv2内网落地全记录

搞离线部署的朋友应该都体会过这种滋味:外面环境里明明跑得好好的服务,一到内网就变得无比拧巴。依赖拉不下来、模型权重动辄几个 G、Docker 镜像在网络不好的时候传到怀疑人生。MonkeyOCRv2 这个项目当初就卡在这一环——一个内部封装的光学字符识别推理…

2026/10/15 8:20:30 阅读更多 →

最新新闻

解决Linux下Python igraph安装时的-lz和-llzma错误

解决Linux下Python igraph安装时的-lz和-llzma错误

1. 问题背景与现象分析最近在Linux环境下安装Python的igraph包时,遇到了一个典型的编译错误:"cannot find -lz llzma: 没有那个文件或目录"。这个报错让很多数据科学和网络分析领域的工作者头疼不已,特别是当我们需要使用igraph这个…

2026/10/15 9:03:31 阅读更多 →
Java停车场管理系统设计与实现

Java停车场管理系统设计与实现

1. 项目背景与核心价值停车场信息管理系统是当前智慧城市建设中的重要组成部分。随着城市化进程加快,车辆保有量持续攀升,传统人工管理方式已无法满足现代停车场的运营需求。这个基于Java开发的系统正是为了解决以下痛点:人工记录效率低下&am…

2026/10/15 9:03:31 阅读更多 →
Agent-Reach:轻量Python CLI封装工具实战指南

Agent-Reach:轻量Python CLI封装工具实战指南

1. “Agent-Reach”不是新框架,而是一把被低估的CLI工程化切刀你搜“Agent-Reach”,首页跳出来的全是GitHub仓库链接、CLI安装命令、MIT License声明,还有大量混杂着“github打不开”“codex cli安装慢”“python下载cv2失败”的搜索词——这…

2026/10/15 9:03:31 阅读更多 →
Prompt-Tuning 原理与实战:从连续提示向量到轻量微调落地

Prompt-Tuning 原理与实战:从连续提示向量到轻量微调落地

简介:本资源是一份系统解读Prompt-Tuning技术的深度综述型学习材料,面向NLP算法工程师、AIGC方向研究者及大模型微调实践者,聚焦解决超大规模语言模型(如GPT-3、ChatGPT)在传统Fine-tuning中面临的语义鸿沟大、标注数据…

2026/10/15 9:03:31 阅读更多 →
JavaScript解构默认值陷阱与防御式编程实践

JavaScript解构默认值陷阱与防御式编程实践

1. 问题现象与背景解析第一次遇到这个问题是在去年重构一个老项目时。当时有个表单处理函数,设计时特意加了默认值:function formatUserData({ name 匿名, age 18 } {}) {// 数据处理逻辑 }测试时传了null值却直接报错,控制台显示Cannot d…

2026/10/15 9:03:31 阅读更多 →
算法面试通关指南:从底层逻辑到实战技巧的完整拆解

算法面试通关指南:从底层逻辑到实战技巧的完整拆解

1. 算法面试到底在考什么:从一道题看穿整场面试的底层逻辑聊算法面试之前,先把这个场景说透。很多人准备算法面试的方式是刷题,刷几百道,然后上场发现面试官问的题没见过,脑子一片空白。问题出在哪?出在没有…

2026/10/15 9:02:30 阅读更多 →

日新闻

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

1. 为什么选择容器化方式部署 LoRa 网络服务LoRa 物联网项目落地时,网络服务器是整个链路的核心枢纽。它负责接收网关上报的数据包、完成去重与解密、再把有效载荷分发给上层应用。早期大家习惯把网络服务器直接装在物理机上,依赖一堆系统库和特定版本的…

2026/10/15 0:00:46 阅读更多 →
共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

1. 共享推理服务里,扩缩容到底难在哪做过大模型推理服务部署的人,大概都经历过这样的场景:一个团队共用一套推理集群,A 业务跑的是 7B 的小模型,B 业务跑的是 72B 的大模型,C 业务白天流量高、晚上几乎归零…

2026/10/15 0:00:46 阅读更多 →
Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

1. 引子:一次内核恐慌引发的追查先从一个真实场景说起。某次我给一台老旧的嵌入式设备折腾系统裁减,为了把启动时间压进两秒以内,我手贱地把一串自认为“没用”的 systemd 服务给 disable 了,其中就包括systemd-remount-fs.servic…

2026/10/15 0:00:46 阅读更多 →

周新闻

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

简介:基于 ARIMA、LSTM、Transformer 等模型的流感时间序列预测 Python 源码,面向计算机相关专业课程设计与期末大作业学生,以及项目实战学习者。内容覆盖预处理、平稳性检验、定阶、残差分析、多模型对比预测的完整时序建模流程,…

2026/10/14 3:30:28 阅读更多 →
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别 做影刀RPA自动化,十个新手有八个栽在"往输入框里填东西"这件事上:要么填不进去,要么填了一半,要么直接把原来内容追加在后面。这背后的根因&…

2026/10/14 16:30:29 阅读更多 →
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容 1. 认识影刀:什么场景该用RPA采小说数据 起点中文网的页面结构相对稳定——分类榜单、书籍详情、章节内容三块独立页面,跳转链路清晰。这种场景非常适合影刀自动化&#x…

2026/10/14 3:29:58 阅读更多 →

月新闻

我发现了一个新思路:用 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/15 0:14:36 阅读更多 →
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/14 22:45:47 阅读更多 →
黑夜航拍船只数据集训练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/14 7:53:34 阅读更多 →