Python抓包文件解析：从pcap中高效提取DNS、HTTP与TCP流数据-北京尧图网络

抓包排障做了好几年我一直觉得pcap文件解析是个“看着简单、上手全是暗坑”的活。你以为拿到一个抓包文件无非就是读点字节、解个协议但真到要从海量数据包里批量提取DNS域名、HTTP请求或者某个TCP流里的下载文件时你会发现事情远没有想象中顺利。这段时间刚好在整理一套Python处理pcap文件的提取方案从二进制格式到库选型再到性能优化都过了一遍写下这篇东西希望对做流量分析、协议调试、安全审计的同行有帮助。整篇博文围绕一条主线用Python从抓包文件里把有价值的数据提取出来。我会先讲文件结构因为不理解结构就没法判断各种解析工具到底替你做了什么再对比几款主流解析库的适用场景然后给出DNS、HTTP、TCP流重组、TLS SNI这些高频提取需求的完整示例代码最后聊聊处理大文件时踩过的性能坑和字节序这类“细节陷阱”。1. 先想明白pcap文件里的数据到底长什么样1.1 pcap存放的是“链路层切片”不是协议解码结果很多人直接用Wireshark打开pcap文件看到的是HTTP、DNS、TCP这些结构化信息下意识以为pcap文件里已经存了解析后的数据。这是第一个误区。pcap文件里只有两类内容抓包时刻的时间戳和当时链路上的一段原始字节。这段原始字节是什么取决于抓包网卡的类型。绝大多数情况下你抓到的是以太网帧也就是从目的MAC开始的一整段数据如果是环回接口抓包可能就是裸的IP包。链路层的头怎么剥、上层是IPv4还是IPv6、再上层是不是TCP/UDP这些都需要自己解析。我习惯把pcap比作“快递底单”上面记录了什么时候、从哪个口子收进来一个包裹但包裹里面装了什么、分了几层包装底单不管。数据提取要做的事就是把这些包裹一个个拆开把里面的清单整理出来。1.2 提取前的两条路线过滤型还是重建型动手写代码前最好先问自己一个问题我到底要提取什么过滤型提取只要从包头拿字段做统计比如某个IP发出了多少DNS查询、某个端口上的HTTP请求分布、一段时间内的连接数变化。这种情况下你完全不需要关心TCP载荷的具体内容只要能把IP头、TCP头、UDP头的关键字段读出来就行速度很快。重建型提取要把属于某个TCP连接的所有报文按序号拼回完整的字节流然后在应用层按语义拆解比如提取一次完整的HTTP响应体、还原FTP文件、从SMTP流量里拿到附件。这种场景必须处理乱序、重传、分片工作量成倍增加。这两条路线决定了工具选型。我在一个内部工具里就翻过车当时试图用某个带完整对象模型的库去遍历一个2GB的pcap结果光为每个包创建对象就花了十几分钟而实际上我只需要拿IP五元组。后来改成轻量解析方式同一样活不到三分钟。1.3 pcap和pcapng别在文件格式上犯迷糊现在很多抓包工具默认保存为pcapng格式它支持多接口、纳秒级时间戳、更长的注释信息。传统的pcap格式是全局文件头加若干包记录简单但扩展性差。Python社区里绝大多数解析库对两种格式都支持但要注意pcap的全局时间为微秒有些特定变体后面会讲是纳秒。pcapng没有唯一的全局文件头而是一系列block每个block都有不同的type字段处理逻辑更复杂。如果你手里的文件是pcapng但你的解析库只支持老pcap最好先用Wireshark、tshark这类工具把它转成pcap格式再处理或者直接用pyshark这类封装了tshark的库让底层工具去处理格式差异。我自己的经验是不要为了省事而对pcapng做半吊子解析格式头一旦理解偏后面所有时间戳和包长度都会错位。2. 徒手拆文件用struct模块读懂二进制格式2.1 全局文件头第一眼要看的字段不止magic numberpcap文件的开头是24字节的全局文件头global header。用Python的struct模块可以一次读出来import struct def read_global_header(f): data f.read(24) if len(data) 24: raise ValueError(文件太短不是合法pcap) magic, version_major, version_minor, thiszone, sigfigs, snaplen, network struct.unpack(IHHiIII, data) return { magic: hex(magic), version: f{version_major}.{version_minor}, thiszone: thiszone, sigfigs: sigfigs, snaplen: snaplen, linktype: network, }这里最重要的不是版本号而是magic number决定了字节序。标准pcap的magic是0xa1b2c3d4以小端方式写入磁盘时你用上面代码里的小端格式解出来正好是0xa1b2c3d4。但如果文件是在大端机器上生成的磁盘上的字节顺序反过来你用小端解就会得到0xd4c3b2a1。更坑的是还有一种纳秒变体magic是0xa1b23c4d以及它的大端形式0x4d3cb2a1。这种文件的时间戳单位是纳秒而不是微秒。判断方法很简单def detect_endian(magic_raw): if magic_raw b\xa1\xb2\xc3\xd4: return , 1_000_000 if magic_raw b\xd4\xc3\xb2\xa1: return , 1_000_000 if magic_raw b\xa1\xb2\x3c\x4d: return , 1_000_000_000 if magic_raw b\x4d\x3c\xb2\xa1: return , 1_000_000_000 raise ValueError(无法识别的pcap字节序)我在实际项目里遇到过某老旧采集器生成的时间戳比正常快1000倍排查半天才发现是纳秒magic被当成了微秒处理。时间戳单位错误后面所有时间维度的统计全部作废。另外顺便看下network字段也就是链路类型LinkType。常见值LinkType值含义链路头长度1Ethernet14字节101RAW IP0字节直接是IP包113Linux cooked capture (SLL)16字节105802.11无线视有无Radiotap头而定知道这个值你才知道一个包记录从第几个字节开始是IP头。很多人踩坑是默认所有文件都是以太网结果遇到环回口抓包文件解析全乱。2.2 包记录头每个包16字节里面藏着两个长度全局文件头之后是若干条包记录packet record。每条记录的头是16字节ts_sec : 时间戳秒 ts_frac : 时间戳小数部分微秒或纳秒 incl_len : 实际保存进文件的字节数 orig_len : 原始包长度其中incl_len是你要读的字节数orig_len是抓包时网络上真实的长度。两者不同通常是因为抓包时设置了snaplen限制比如只捕获每个包前96字节那么incl_len小于orig_len。提取数据时一定要以incl_len为准否则可能越界。一个完整的pcap读取循环可以这样写def iter_pcap_raw(path): with open(path, rb) as f: gh read_global_header(f) endian gh[byte_order] ts_unit gh[ts_unit] while True: rec_hdr f.read(16) if len(rec_hdr) 16: break ts_sec, ts_frac, incl_len, orig_len struct.unpack(endian IIII, rec_hdr) pkt_data f.read(incl_len) if len(pkt_data) incl_len: break # 文件被截断 timestamp ts_sec ts_frac / ts_unit yield timestamp, pkt_data这套手写代码虽然简单却让我想清楚了很多问题为什么有些库解析慢、为什么有的文件时间戳是负数、为什么文件里会出现半个包。建议每个想深入做pcap分析的人都先手写一遍这个循环再上第三方库否则出了问题你根本不知道是库的bug还是你的用法不对。2.3 顺着链路层往上剥以太网、VLAN、IP分片拿到的pkt_data是链路层字节流。以太网头是14字节6字节目的MAC、6字节源MAC、2字节EtherType。EtherType常见的有0x0800IPv4、0x86DDIPv6、0x8100VLAN Tag。如果看到VLAN Tag就得在以太网头后面跳过4字节的Tag信息再读一次EtherType。这个细节看似不起眼但我在解析带VLAN的抓包时反复出错过直接用固定偏移去取IP头结果把VLAN Tag当成了IP头的一部分源地址和目标地址全部乱七八糟。到IP层还要注意分片。如果IP头里的Fragment Offset非零或者More Fragments标志置位说明这不是一个完整的L4报文。提取TCP/UDP端口时如果拿分片包去解极大概率会读到错误端口。所以提取端口之前的正确姿势是先检查IP头分片标志有分片就跳过或先重组。3. 解析库选型Scapy、dpkt、pyshark到底怎么选3.1 Scapy功能完整但小心“对象爆炸”Scapy是Python生态里最常用的协议分析库它的API非常友好rdpcap()可以直接把文件读成一组数据包然后pkt[IP].src这样拿字段。from scapy.all import rdpcap packets rdpcap(traffic.pcap) for pkt in packets: if pkt.haslayer(IP): src pkt[IP].src dst pkt[IP].dst # 提取你需要的字段Scapy的好处是协议库极其丰富TCP、UDP、DNS、HTTP、TLS等都有对应的解析字段写交互式分析代码非常舒服。坏处也很明显每个包都被包装成完整的Scapy层对象对象构建开销很大。我曾经解析一个约500MB的pcap用rdpcap把全部包加载进内存机器直接吃掉了2GB以上内存极其难受。所以我的建议是文件小于几百MB、包数量在几十万级用Scapy很爽大文件优先用PcapReader做迭代而不是rdpcap一次性加载如果只是统计或按固定字段提取不建议用Scapy处理速度撑不住。3.2 dpkt轻量、快适合批量离线提取dpkt是一款轻量级解析库它把包解析成简单的Python对象字段通过属性访问底层是偏C式的高效实现。同样读取一个pcapdpkt比Scapy快很多倍。import dpkt with open(traffic.pcap, rb) as f: pcap dpkt.pcap.Reader(f) for ts, buf in pcap: eth dpkt.ethernet.Ethernet(buf) if eth.type ! dpkt.ethernet.ETH_TYPE_IP: continue ip eth.data if isinstance(ip, dpkt.ip.IP): src_ip ip.src protocol ip.pdpkt的缺点也很明显它对协议支持程度不如Scapy那么全面某些应用层协议的解析需要自己写。但对绝大多数网络统计和字段提取场景dpkt完全够用。处理生产环境里的几GB抓包我基本默认选dpkt除非需要Scapy的场景化API。3.3 pyshark调用Wireshark的协议引擎pyshark本质上不是纯Python解析它把分析工作交给tshark进程Python负责管理和读取输出。它的最大优势是协议支持等于Wireshark的协议支持什么QUIC、HTTPS、SMB都能给你解出结构化字段。import pyshark caps pyshark.FileCapture(traffic.pcap, display_filterdns) for packet in caps: if hasattr(packet, dns): print(packet.dns.qry_name)需要注意的是pyshark的每一次读取都要启动外部进程做协议解码性能开销比dpkt大很多而且需要系统装了tshark。如果要做的是深层次协议解析比如解析某个小众协议我会用pyshark辅助排查但如果要批量提取字段还是建议dpkt。3.4 选型对照总结库协议覆盖解析速度内存占用依赖适合场景Scapy非常全面慢高纯Python交互分析、小型pcap、敏捷调研dpkt较全面快低纯Python批量离线提取、大文件流式处理pyshark极全面同Wireshark慢高依赖tshark复杂协议取证、临时解码我实际工作里的组合拳是先用Scapy做小样本交互探测确认字段名再用dpkt写正式批量提取脚本遇到dpkt解不了的应用层字段再用pyshark单独跑。4. 数据提取实战DNS、HTTP、TCP流重组、TLS SNI4.1 从抓包里提取DNS查询域名DNS是最容易上手的数据提取对象。DNS报文一般跑在UDP 53端口上解析流程是读到UDP负载后按DNS协议格式找Query字段。用dpkt可以这样写import dpkt from dpkt.dns import DNS from dpkt.ip import IP from dpkt.udp import UDP from dpkt.ethernet import Ethernet, ETH_TYPE_IP def extract_dns_queries(pcap_path): with open(pcap_path, rb) as f: pcap dpkt.pcap.Reader(f) for ts, buf in pcap: eth Ethernet(buf) if eth.type ! ETH_TYPE_IP: continue ip eth.data if ip.p ! dpkt.ip.IP_PROTO_UDP: continue udp ip.data if udp.dport ! 53 and udp.sport ! 53: continue try: dns DNS(udp.data) if dns.qd: for q in dns.qd: yield ts, q.name, q.type except Exception: # 有些报文只是TCP握手残留或畸形DNS忽略不计 continue这里有个工程细节DNS解析可能在UDP之外还有TCP 53的fallback尤其是大响应。如果只抓UDP会漏掉一部分查询需要后续再补一个TCP 53的解析分支。4.2 提取HTTP请求的Method、Host、URI和User-AgentHTTP的提取比DNS复杂因为它跑在TCP之上首先要从IP层取到TCP载荷然后解析请求文本。粗略提取可以这样import dpkt import re def extract_http_requests(pcap_path): with open(pcap_path, rb) as f: pcap dpkt.pcap.Reader(f) for ts, buf in pcap: eth dpkt.ethernet.Ethernet(buf) if eth.type ! dpkt.ethernet.ETH_TYPE_IP: continue ip eth.data if ip.p ! dpkt.ip.IP_PROTO_TCP: continue tcp ip.data payload bytes(tcp.data) if not payload: continue if payload[:3] in (bGET, bPOST, bPUT, bHEAD, bDELETE): # 用简单的行解析提取请求行和Header text payload.decode(latin1, errorsreplace) lines text.split(\r\n) if lines: request_line lines[0] host user_agent for line in lines[1:]: if line.lower().startswith(host:): host line.split(:, 1)[1].strip() elif line.lower().startswith(user-agent:): user_agent line.split(:, 1)[1].strip() yield request_line, host, user_agent这个写法简单但有一个致命问题TCP分段。如果一个HTTP请求被分成两个TCP段你会发现第一个包里只有GET /ind第二个包里才有ex.html HTTP/1.1。粗暴的做法是把符合源目端口、且方向一致的TCP载荷累积到一个缓冲区等看到完整请求头再提取。这也就是4.3要讲的TCP流重组。4.3 TCP流重组还原完整对话内容TCP流提取是数据提取里最核心的工作。不夸张地说很多安全分析场景里拿不到应用层数据都是卡在这一步。TCP是字节流协议应用层的一条完整消息可能被拆成多个报文也可能多个消息合并到一个报文里。只有把每个方向上的载荷按序号拼起来才能得到可用的数据。我采用的方法是以四元组源IP、源端口、目的IP、目的端口为key维护两段缓冲区。每看到一个TCP包先取出其TCP载荷紧接着按seq len(payload)的期望序号放到缓冲区对应的偏移位置。如果出现seq小于期望值说明有重传直接跳过如果seq大于期望值说明中间有缺失先留着间隙位。为了简单很多内部工具只按方向简单拼接不处理乱序这对大多数HTTP请求已经足够但在要求精确的场景里还不够。处理完拼接后再在上层做HTTP报文切分。核心思路是先找\r\n\r\n切出Header部分然后用Content-Length或Transfer-Encoding判断body长度。我在自己的项目里就靠这套逻辑从抓包里还原出完整的文件下载连接拿到了实际传输的文件名和大小。TCP流重组会带来两个衍生需求一是TCP时间戳的计算二是流量方向反转。比如一个请求发送后响应方向是相反的判断哪个方向是“客户端”需要看最早发起SYN的一方。这个判断做错了后面提取的HTTP响应也全是错的。4.4 TLS SNI提取无需解密就能知道访问了哪个域名TLS加密流量无法直接看到HTTP内容但是ClientHello阶段客户端会明文发送SNIServer Name Indication也就是它想访问的域名。这个字段在TLS记录里是明文抓包时可以直接提取。TLS ClientHello结构虽然有点长但做一个最小解析并不复杂def extract_sni(data): # data是TLS记录载荷record type0x16 Handshake if data[0] ! 0x16: return None # Handshake header: type(1) length(3) if data[5] ! 0x01: return None # 跳过 handshake type length pos 9 # 跳过 client_version(2) random(32) pos 34 # session_id session_id_len data[pos] pos 1 session_id_len # cipher_suites cipher_len int.from_bytes(data[pos:pos2], big) pos 2 cipher_len # compression_methods comp_len data[pos] pos 1 comp_len # extensions if pos 2 len(data): return None ext_total_len int.from_bytes(data[pos:pos2], big) pos 2 while pos len(data) and pos 4 len(data): ext_type int.from_bytes(data[pos:pos2], big) ext_len int.from_bytes(data[pos2:pos4], big) if ext_type 0x0000: # SNI extension_data data[pos4:pos4ext_len] # server_name_list_length entry_type(1)name_len(2)name offset 2 name_len int.from_bytes(extension_data[offset:offset2], big) sni extension_data[offset2:offset2name_len].decode(utf-8, errorsreplace) return sni pos 4 ext_len return None这个函数的核心逻辑是把TLS握手里的extension逐个解析直到找到type为0x0000的SNI extension。实际应用里我一般只扫描TCP 443端口上的首包跟DNS查询做交叉验证用来发现“解析了域名但没走标准查询”的情况效果很好。5. 性能优化当我处理一个2GB的pcap时做了什么5.1 不要一上来就rdpcap很多新手拿到pcap第一反应是rdpcap(file)然后对全体包做处理。这个做法在文件小于100MB时问题不大文件一大就崩。某次客户一提供就是2.3GB的抓包我一开始用rdpcap读内存直接冲到3.5GB还没开始统计就卡死了。正确姿势是流式迭代。dpkt的Reader本身就是迭代器每次只解析一个包处理完就释放内存占用几乎恒定。5.2 用生成器封装提取逻辑避免中间大列表把提取逻辑写成generator可以大幅降低内存占用。def extract_all(pcap_path): with open(pcap_path, rb) as f: pcap dpkt.pcap.Reader(f) for ts, buf in pcap: try: result parse_packet(ts, buf) except Exception: continue if result: yield result # 使用生成器边遍历边写入目标文件 with open(output.csv, w) as out: for item in extract_all(big.pcap): out.write(...)有些提取任务要求把结果放在内存里做关联这时候可以分两个阶段先把提取的字段写成CSV/parquet文件再对文件做关联分析。不要试图把所有包留在内存。5.3 按包类型快速分流减少不必要的深度解析对大文件性能影响最大的往往是“把每个包都完整解析成协议对象”。优化方案是按端口和协议号快速分流如果目标是DNS只对UDP 53端口的包做深度DNS解析其他包直接跳过如果目标是HTTP先看TCP端口是80或8080再尝试切HTTP头如果目标是SNI只处理TCP 443端口的TLS握手首包。我还习惯用一个简单的位运算提前判断IP版本和协议号避免不必要的对象创建。比如用ip.p比较协议号时直接读字节比构造IP对象快得多。5.4 多进程处理按文件偏移切分Python处理单包性能很难高到哪去但可以横向扩展。一种有效方案是按包边界把pcap切成多个独立区域每个进程各读一段先遍历一次文件记录每个包记录头的偏移量把偏移量列表按数量均分成N个子区间用multiprocessing.Pool启动N个worker每个worker从指定的偏移开始读取最后合并各区间的提取结果。这种方法要注意pcap文件头的24字节只有第一个进程能读其他进程要从记录头区域开始并且每个worker要自己判断字节序。实测一个2GB文件切成8个区在8核机器上提取DNS查询耗时能从6分钟压到1分钟左右提升非常明显。5.5 分阶段工具链tshark粗滤 Python精提取如果pcap里混杂了成百上千种流量直接上Python全量解析还是很浪费。我的做法是先让tshark按显示过滤条件粗滤一遍产出一个小得多的文件再用Python对过滤结果精提取。比如tshark -r big.pcap -Y dns.flags.response 0 -w dns_queries.pcap再跑Python脚本提取具体字段原因是tshark过滤引擎是C语言实现性能非常快而Python的优势在于过滤后的业务逻辑处理。两头各取所长工具链整体效率高很多。6. 绕不开的坑字节序、VLAN、分片这些细节会随时让你翻车6.1 字节序判断错误的连锁反应前文提到过magic number决定字节序但很多人只是抄了代码没真正理解。字节序如果判断错时间戳秒和微秒会颠倒包长度会变成一个巨大数字read(incl_len)会直接读到文件尾部。风险极大。我自己的排查经验是拿到一个陌生来源的pcap先用十六进制工具看前4个字节肉眼确认magic排列再决定用什么字节序。这个习惯帮我避免了好几次解析结果全错的问题。6.2 VLAN标签和QinQ让偏移量变成“动态”的以太网头不总是14字节。出现VLAN时原始帧变成目的MAC(6) 源MAC(6) 0x8100(2) Tag(2) EtherType(2) payload外层VLAN还可能再嵌套一层也就是QinQ。如果程序写死EtherType偏移量遇到VLAN帧会直接把EtherType读成0x8100后面所有解析全部漂移。建议在解析时写一个循环剥Tagdef resolve_ethertype_and_offset(data): eth_type int.from_bytes(data[12:14], big) offset 14 while eth_type in (0x8100, 0x88a8, 0x9100): # 802.1Q / QinQ 等 eth_type int.from_bytes(data[offset2:offset4], big) if offset 4 len(data) else 0 offset 4 return eth_type, offset这个函数让后续提取IP头不会因为VLAN标签而错位非常关键。6.3 IP分片不要用分片包去解TCP/UDP端口分片对提取数据的影响主要体现在端口和载荷上。TCP头只有第一个分片里才有后续分片的数据从IP载荷中间开始按TCP头偏移去解析会读到错的端口和序号。稳妥的做法是如果Fragment Offset非零直接跳过不做L4解析如果只关心载荷内容就要按IP ID src_ip dst_ip protocol进行分片重组攒齐后按偏移拼好再提取。分片重组会让脚本复杂不少所以一般我在处理小流量抓包时选择“跳过非首片”只有做载荷还原时才实现完整重组。6.4 时间戳和时区问题pcap里的秒是UTC时间thiszone字段是时区偏移但大多数抓包工具并不写入有效的thiszone默认是0。这意味着你把时间戳转成本地时间时必须自己加上时区偏移。另外有些采集器时钟没同步提取出来的时间线会有漂移。做统计分析没关系但做关联取证时一定要先校准时间否则按时间排序的流量会话顺序可能是错的。6.5 输出设计的建议别把所有结果堆进一个CSV提取出来的数据字段类型差异很大DNS查询是字符串HTTP请求里有Method和HeaderTCP流重组后的载荷是二进制。把它硬塞进一个CSV会很别扭。我推荐按“事件表”设计输出字段类型说明timestampfloat提取事件发生时间protocolstrdns / http / tlssrc_ipstr源IPsrc_portint源端口dst_ipstr目的IPdst_portint目的端口detailstr / bytes不同协议的具体字段拼接还应该给每条事件分配一个stream_id用于把同一条TCP流里的多个HTTP事件关联起来。这样后续做聚合分析时不需要重新解析pcap。如果你要落盘存储建议用parquet或jsonl而不是CSV因为字段类型混合和数组嵌套在CSV里很难表达。我在这块吃过亏最开始全输出CSV结果面对一个包含多个Header值的HTTP请求时不得不用分号拼字符串后面对接分析工具时浪费了大量清理时间。最后补充一点个人的实操体会做了这么多pcap解析项目我最大的感想是数据提取的真正难点不在于“读文件”而在于“读对字段”。协议分层的每个边界都必须想清楚字节序、VLAN、分片、TCP重组这些细节每一个都可能让结果从“看起来不错”变成“完全不能用”。建议你拿到一个新的抓包文件时先用Wireshark肉眼确认几个关键包的协议和字段再写解析代码。拿小样本文件断点打印中间字段跟Wireshark对照一次确认无误后再上大文件。这一步看似多花十分钟实际上能帮你省下后面调试一整天的时间。如果你是初次接触可以先把第2节的手写循环跑通再用dpkt做一次同样的提取对比结果是否一致。两种方法交叉验证过一次后你基本会对pcap解析建立很强的信心。后续不管换什么库、处理什么格式都不容易翻车。

Python抓包文件解析：从pcap中高效提取DNS、HTTP与TCP流数据

相关推荐

工业AI边缘部署实战：从硬件选型到现场调试的避坑指南

回归还是分类：业务建模选型的底层逻辑与实战指南

C++性能优化4大技巧：Awesome-QuantDev-Learn智能指针、移动语义与模板元编程实战指南

更多资讯

SD NAND为何内置NAND Flash？NOR与NAND选型核心解析

【ESP32入门】Windows 下 ESP-IDF V6.1 示例运行（下）：hello_world 创建、编译烧录、串口监视 + FAQ

TC275 Flash驱动RAM加载实战：解决擦写时自执行冲突

ISO 26262功能安全落地：从ASIL定级到安全机制设计全链路解析

秒杀系统整合himily：分布式事务与高并发架构实战

纪录片播放量预测：面向长尾内容的可解释机器学习实践

今日更新

小波包能量谱原理与MATLAB实现：从频带分解到故障特征提取

基于LSTM的网易云音乐评论情感分析：数据清洗与模型调优实战

Alpha-Beta剪枝与极大极小值算法：博弈树搜索原理与实战优化

本周精选

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

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

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

本月热门

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

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

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

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