性能测试中的唯一标识：从压测事故到JMeter实战方案-北京尧图网络

1. 从一次压测事故说起唯一标识为什么是个大问题先讲个我亲身经历的现场。去年做某个核心交易链路的压力测试并发量刚压到 500 线程后端就开始报主键冲突。开发第一反应是数据库问题盯着慢查询日志看了半天也没头绪。后来把日志翻到业务层才发现每次压测请求里携带的单据号几乎一模一样大量请求把同一把业务钥匙打到了后端数据库唯一索引直接拦住了一堆本该正常落库的请求。这就是性能测试里最典型的唯一标识问题——你以为你在模拟 500 个真实用户实际上发出的请求长得跟克隆人一样后端连你是你、我是我都分不清。这类问题不仅在接口压测里出现在手机设备相关的性能测试场景里尤其明显。比如你要压测一个推送服务或者测一个设备注册接口后端往往会用设备唯一标识比如 Android 的 OAID、iOS 的 IDFA、或者是自定义的设备指纹来路由、限流、去重。如果你压测时每台虚拟用户都发同一串设备标识那测出来的结果根本不是真实容量而是单设备被限流后的表现。说白了性能测试里的唯一标识核心就一句话让每个并发请求在服务端看来都是独立、可区分的真实个体。它不只是一个随机字符串的问题而是牵涉到会话保持、数据隔离、结果追踪、分布式环境下的 ID 生成策略等一系列问题。这篇文章我就把自己踩过的坑、用过的方案、总结出的检查清单全部摊开聊一聊希望能帮你在下次压测前少走弯路。2. 唯一标识在性能测试里的三个核心用途不只是去重这么简单很多人一听说性能测试中的唯一标识第一反应就是找个 UUID 拼上去不就完了。真这么简单的话就不会有那么多压测事故现场了。我梳理下来唯一标识在性能测试里至少承担三个职责缺一个都会让测试结果失真。2.1 会话关联让每个虚拟用户活起来压测过带登录态的接口时你就知道JMeter 里通常要先跑一个登录请求拿到 Token再带着 Token 去压业务接口。这个时候唯一标识承担的是会话身份。如果没有它或者它被错误地设计成了固定值那么服务端根本无法区分这是 500 个不同的用户只会认为这 1 个用户在疯狂刷请求。举个具体例子你压测的是一个购物车结算接口接口要求传入 userId。如果所有线程都用同一个 userId那么问题立刻变成——所有线程在抢同一份购物车数据。加锁、并发修改、缓存击穿……这些行为全都在围绕一个数据体发生而你原本想测的500 人同时结算就变成了500 个请求反复打同一个人的购物车。结果出来以后数值可能还行但性能瓶颈的定位会完全偏掉。你可能会在代码里找到一堆积压的锁竞争问题但这些问题在真实场景里根本不成立白白浪费排查时间。2.2 数据隔离压测数据不能互相污染做性能测试多少都要往库里写数据。如果没有唯一标识两个线程生成的订单号撞了写库就直接失败或者一个线程的更新操作把另一个线程刚写入的数据给覆盖了后面断言的时候怎么查数据都不对。我见过最离谱的一次是压测一个对账系统测试脚本里硬编码了一个固定的批次号结果几千个事务全部往同一个批次文件里追加。跑完以后查数据库那个批次的数据量暴涨了几十倍而其他批次空空如也。开发看着这个数据分布差点以为线上出了故障。所以唯一标识在压测数据层面就是保证数据隔离的护城河。每个线程、每次迭代生成的数据在业务上互不干扰才能保证最终结果可统计、可对账、可回滚。2.3 结果追踪让异常定位有迹可循还有一类容易被忽视的作用——压测后的日志追踪。压测过程中如果出现超时、报错你要拿着请求里的唯一标识去日志系统里捞对应的调用链。如果所有请求共用同一个标识日志里搜出来几百页都是同一条链路你根本不知道是哪个线程、哪个时刻、哪个数据导致的问题。有一次我们做全链路压测为了排查一个偶发的 500 错误我在日志里按 traceId 搜索。大部分请求的 traceId 都能精准定位到具体的调用链唯独少数请求 grep 出来找不到对应记录。后来发现是脚本里的 traceId 生成逻辑用了系统时间加随机数在并发量高的时候两个线程在同一毫秒生成了相同的值日志系统按 traceId 索引时就出现了串链。这个坑直接把我引向了对 ID 生成算法本身的研究——所以下面这部分是整篇文章真正的干货。3. 主流唯一标识生成方案对比从 UUID 到雪花算法的选型逻辑生成唯一标识的方案多的是但性能测试场景有自己的特殊性并发量大、生成频率高、且要求绝对可辨识。不是所有方案都适合直接搬过来用我拿生产环境的经验来对照着说。3.1 UUID / 随机字符串最简单但有隐藏成本UUID 是很多人第一个想到的方案JMeter 里也有现成的${__UUID()}函数。uuid-1 550e8400-e29b-41d4-a716-446655440000 uuid-2 550e8400-e29b-41d4-a716-446655440001好处是零成本、无需依赖外部服务、基本不会重复。但毛病有三个长度太长。一个标准 UUID 是 36 个字符如果在 URL、Header、报文体里反复传递网络包体积会明显增加。在高并发下这会让请求体变大不少间接拉高带宽开销。无序性。UUID 不携带业务语义分布式数据库按 ID 建索引的时候随机插入会导致页分裂性能测试如果直接拿 UUID 写库数据库的写入性能会被随机 IO拖垮一部分这部分损耗会被错认为被测系统的真实瓶颈。排查不便。如果你是靠唯一标识去关联日志UUID 的一串无规则字符在 grep 的时候非常不友好眼睛看半天都看不出来自哪个线程、哪次迭代。所以我的结论是UUID 适合做一次性请求的防重标识不适合作为压测主键或者高频写入的关联字段。3.2 时间戳随机数最常踩坑的方案JMeter 里很多人喜欢拼时间戳比如${__time(yyyyMMddHHmmssSSS)}再加上随机数。这个方案看起来很灵活但在高并发场景下有一个致命缺陷同一毫秒内随机数可能碰撞。我之前的那个 traceId 串链事故就是这一款。JMeter 的 Random 函数在默认种子下并发数一旦上来碰撞概率远超你的直觉。更可怕的是这种碰撞不是报错而是静默发生——只是日志串了数据库也没拦你。排查的时候是需要花大力气才能发现的隐性 bug。3.3 雪花算法Snowflake生产环境最常见的答案雪花算法是我在实际压测中用得最多的方案。它用一个 64 位的长整型表示 ID结构大致是第 1 位符号位固定为 041 位毫秒时间戳10 位机器标识数据中心节点12 位同一毫秒内的自增序列因为 ID 和时间的单调递增趋势强相关写数据库时性能友好因为融入了机器标识和自增序列单机并发下几乎不会重复。在 JMeter 里需要稍微动点手用 BeanShell 或 JSR223 脚本实现但换来的是稳定可靠的唯一性。这里有一个大家容易忽略的问题雪花算法的机器标识位在压测脚本里怎么处理。如果压测机是一台机器上的 500 个线程机器标识位可以全都一样靠序列位保证唯一。但如果是分布式压测比如多台施压机同时压每台机器必须分配不同的 workerId否则两台机器在同一毫秒生成的 ID 序列就会撞车。这就是为什么我后面建议用带 workerId 配置的方案而不是网上随便抄一段写死 workerId0 的脚本。3.4 集中式发号器高要求场景的正规军还有一些业务场景要求唯一标识具备业务语义比如订单号要体现日期、业务线、分库分表位。这时候你要么在压测脚本里模拟同样的生成规则要么直接调用被测系统的发号服务接口获取。我见过有人为了实现真实场景直接在压测脚本里每发一个请求都先调一次发号服务。这在低并发下没问题但高并发下问题就来了发号器服务本身会成为新的瓶颈而且它会增加一次额外的网络延迟。更合理的做法是把发号规则在脚本里本地实现然后压测验证完毕后再单独针对发号服务做专项压测。压测的目标是测被测系统而不是测你的脚本逻辑这个边界要拎清楚。3.5 方案选型决策表有了上面的对比选型逻辑其实很清晰。我直接给一张自己压测前会对照的表方案优点缺点适用场景UUID零成本、无依赖太长、无序、不友好一次性消息防重、非持久化数据时间戳随机数易实现、可读性好高并发碰撞概率大低并发、可容忍小概率冲突雪花算法有序、高性能、不碰撞实现稍复杂、依赖时钟高并发压测、数据库写入、日志追踪集中式发号业务语义强、全局可靠额外开销、易成瓶颈需要强业务编号、验证发号服务本身4. 从入口到断言在 JMeter 里构建一套完整的唯一标识体系这一段我纯讲实操。毕竟方案说得再好落地到 JMeter 里还是有很多细节坑。我以最常见的压测脚本为例讲清楚从入口到断言的每一步该怎么设计。4.1 全局配置用一个变量统一管理标识生成规则刚开始写 JMeter 脚本的人最容易犯的错就是在每一个取样器里各自生成唯一标识。比如登录接口拼了个 userId下单接口又拼了一个新的 userId两个 ID 之间没有任何关联。服务端一看登录的是 A 用户下单的是 B 用户这个会话根本对不上。测出来的数据要么大量报登录态失效要么下单全部失败却在断言里看不出来。建议的做法是在 JMeter 的用户自定义变量或者 setUp 线程组里预先为每个线程生成一个全局会话标识然后通过${userId}这种变量引用的方式在各个取样器间传递。比如用 JSR223 预处理脚本生成一个全局 userId// 在 setUp 线程组中每个线程独立执行一次 String userId U System.currentTimeMillis() _ Thread.currentThread().getId() _ (int)(Math.random() * 100000); vars.put(userId, userId); vars.put(deviceId, D userId.hashCode());这里我用时间戳线程 ID 随机数的组合目的是让每个线程持有独立的用户身份同时在 JVM 内即使两个线程同时执行也不会因为随机数碰撞导致 userId 一致。你仔细想一下Thread.currentThread().getId() 本身就是唯一的在 JMeter 非共享线程池里这个值几乎可以作为天然的唯一因子。4.2 请求体中的唯一标识注入别把变量写死实际压测中唯一标识通常要出现在三个位置Header、URL 参数、请求体。很多接口要求设备指纹字段传设备唯一标识这在手机设备相关的性能测试里尤其常见。你压测一个推送网关的时候Header 里的 deviceId 是后端路由的核心依据。如果 500 个并发线程全部传同一个 deviceId推送网关会被压垮吗不一定。但它会触发针对单设备的限流策略导致压测 TPS 上不去而你还会误以为是网关容量不够。正确做法是在 HTTP Header Manager 里这样配置deviceId: ${deviceId}在请求体的 JSON 里同样引用{ userId: ${userId}, deviceId: ${deviceId}, requestId: ${__time(yyyyMMddHHmmssSSS)}-${__threadNum} }注意最后这个 requestId我特意加了__threadNum。你可能会问__time的毫秒精度加线程号够不够唯一答案是在单台压力机场景下基本够。但在分布式中仍然不够可靠建议换成雪花 ID 方案后面我专门写了一段可直接复用的脚本。4.3 高并发下的唯一标识重复最常见的现场还原这是我自己踩过、也帮别人排查过最多的问题。现象如下压测跑了 3 分钟数据库里出现大量唯一键冲突或者日志平台里有大量数据串链。根因往往是这一步——JMeter 的变量作用域。很多人喜欢把用户自定义变量里的随机值直接写成${__Random(1,100000)}以为这个函数每请求一次就会重新生成。但实际上如果放在用户自定义变量配置元件里它只会在线程启动时生成一次整个线程后续的所有请求都会复用这个固定值。也就是说你的 500 个线程确实拿到了 500 个不同的随机值但如果脚本设计成了循环多次执行比如循环 100 次那么同一个线程的 100 次请求始终带着同一个 ID。这在某些场景下是有意的模拟同一个用户的重复操作但在另一些场景下就是致命的——你要模拟的是每次独立的新请求却变成了同一个人反复提交。区分这两种场景的方法很简单看业务语义是用户会话级还是单次请求级。用户会话级的标识userId、token、deviceId应当在线程内保持不变单次请求级的标识requestId、traceId、orderNo则必须每次迭代重新生成。4.4 每次迭代重新生成JSR223 变量的正确用法所以我在 JSR223 预处理脚本里会把变量分为两类。一类放在 setUp 里生成全线程共享不变一类放在取样器前的JSR223 预处理程序里每次迭代都重新生成// 放在业务请求前的 JSR223 预处理程序 // 生成单次请求的唯一标识每次迭代都会执行 String iterationId UUID.randomUUID().toString().replace(-, ); vars.put(requestId, iterationId); vars.put(orderNo, O System.currentTimeMillis() _ vars.getIteration());这里的核心在于位置——JSR223 预处理程序放在采样器子节点下会随采样器每次迭代执行放在线程组层面则只会在线程启动时执行一次。这个位置差异就是很多人困惑为什么我的变量不更新的根源。另外说一句UUID.randomUUID()在高并发、单 JVM 内也会引入同步锁竞争SecureRandom 的种子生成但 JMeter 单机压测的性能损耗可以忽略。如果你做的是上万并发再把这段换成我下面要说的高性能版本。4.5 高性能雪花 ID 生成脚本可直接抄为了兼顾可读性和性能我推荐在 JMeter 的 JSR223 取样器里实现一个精简版雪花 ID// JSR223 预处理脚本 // 每次迭代调用生成一个全局唯一的长整型 ID long workerId 1; // 分布式压测时每台施压机配置不同值 long sequence 0; long lastTimestamp -1; long timestamp System.currentTimeMillis(); if (timestamp lastTimestamp) { sequence (sequence 1) 4095; // 4095 2^12 - 1 if (sequence 0) { timestamp tilNextMillis(lastTimestamp); } } else { sequence 0; } lastTimestamp timestamp; long id ((timestamp - 1288834974657L) 22) | (workerId 12) | sequence; vars.put(snowflakeId, String.valueOf(id));注意这段脚本里的lastTimestamp是局部变量但如果放在 JSR223 里每次执行都重新初始化sequence的防碰撞效果就打了折扣。正确做法是把它写成一个 Groovy 类或者用props保存状态。我在实际使用时是直接放到 JSR223 的静态变量里维护或者干脆用现成的开源雪花 ID 工具类JMeter 的 lib 目录里放一个 jar 包脚本里直接 new 出来调用。这个操作不复杂网上也有很多现成的库核心要点就是 workerId 必须能在分布式压测中区分开。4.6 断言和数据校验标识生成得对不对得用数据说话标识生成完不是就完了你还需要验证它是否真的起到了隔离效果。我在每次压测脚本里都会加一个后置断言或者结果处理逻辑响应断言判断返回体里的data.id是否和请求里的 requestId 一一对应防止服务端做了一些 ID 归一化处理导致数据对不上。数据库校验压测结束后直接查数据库统计唯一标识的 distinct 数量。如果 distinct 数量远远小于总请求数说明脚本里还是存在复用问题。日志样例抽取在压测过程中每过一段时间就随手从日志平台捞几条请求人工看一眼标识是否独立。还有一种偷懒但很有效的办法在聚合报告里加一列响应信息。如果你在请求里传入 requestId并让服务端在响应里原样返回那么聚合报告里的样本标签就能展示出唯一的请求样本。一旦看到样本标签里的 ID 大量重复脚本问题一目了然。5. 手机设备唯一标识场景压测推送、注册接口时最容易踩的坑前面提到过手机设备唯一标识在性能测试里是一个非常特殊的领域。原因在于设备标识在后端不仅仅是一个 ID它常常绑定了推送 Token、APNs 注册状态、设备频率控制、地区路由等信息。5.1 设备指纹的组成与模拟策略真实设备唯一标识比如 OAID、IDFA、IMEI通常有严格的格式校验。你用 JMeter 造数据的时候不能随便填 16 个随机数字后端一校验格式就把请求拦了。我在压测一个设备注册接口时一开始用了${__Random(1,999999999)}结果接口大量返回设备标识格式不合法我一度以为是压测工具被服务端识别出来了后来仔细看文档才发现OAID 的格式要求是 32 位十六进制字符串。所以做手机设备相关的性能测试第一步是读懂被测系统的设备标识规则。如果接口只要求一个不透明字符串你可以自由发挥如果要求特定格式务必先用少量样本验证能通过校验再上压测。5.2 单用户多设备与单设备多用户的边界很多压测需求会混淆两个概念是要测一万个用户同时注册每个用户对应一个新设备还是一个设备频繁触发推送模拟单个设备短时间大量请求。这两种场景对唯一标识的生成策略要求完全相反前者要求每个线程每次迭代都生成不同的设备标识模拟设备增量后者要求所有线程共用同一个设备标识集中验证单设备的频率控制和推送链路容量。如果你搞反了测出来的数据就会非常离谱——单设备场景用随机设备标识测后端的所有限流、去重策略全部失效实际容量会被高估新设备注册场景用固定设备标识测后端误判为重复注册大量请求被拦截容量被严重低估。5.3 设备标识与用户绑定关系的数据准备在真实场景里设备标识和用户 ID 是存在绑定关系的而且这个绑定关系通常存储在服务端。压测时你要么造一批真实的绑定数据插入数据库要么在脚本里维护一个线程安全的映射表。我在脚本里的做法是在 setUp 阶段读取一个 CSV 文件每行存一个用户ID 设备ID的关联对每个线程从 CSV 里取一行整个压测过程始终使用这一对绑定关系。这个方法带来的好处是——压测数据完全可复现。压测结束后你可以拿着 CSV 里的数据和数据库里的结果做精确比对哪个用户、哪个设备、哪次请求产生了异常一目了然。5.4 设备唯一标识的时间维度过期与刷新还有一个容易被忽略的点设备标识可能存在有效期。比如 iOS 的 IDFA 在用户重置系统后会变化某些业务的后端 Token 会在一定时长后过期。如果你的压测跑的是长时间稳定性测试比如 8 小时以上固定的一批设备标识可能在中途全部失效后续的压测就变成了纯报错压测。解决方案是在压测脚本里加入周期性刷新逻辑。比如每跑 30 分钟就重新生成一批设备标识同时触发一次重新登录/注册流程确保后续请求始终携带的是有效标识。我在一次推送网关的长稳定测试里就因为这个坑废了一整轮数据从那以后所有超过 1 小时的测试我都会提前确认设备标识的有效期并且把刷新逻辑写进脚本。6. 分布式压测下的唯一标识多机并发不重复的三种做法分布式压测是最容易暴露唯一标识问题的地方。原因很简单——单机上的线程号、时间戳、随机数在多台机器之间不具备天然隔离性。6.1 用物理机标识做隔离这是最基础的做法。每台施压机在启动脚本前在本地文件中配置一个唯一的 machineId然后生成唯一标识时把这个 machineId 拼进去。比如requestId 压测机IP最后两位时间戳线程号但注意如果不用 IP 而是一个自定义编号你要保证每个 Agent 的配置不重复。我在公司内部用的是压测机的内网 IP 后两位虽然简单但已经能覆盖绝大部分场景。6.2 时间戳随机数线程号的组合优化如果你不太 care 格式可以考虑这个组合前提是做好碰撞概率评估。假设你有 10 台施压机每台 500 线程总计 5000 并发每秒可能生成 5000 个标识。时间戳精确到毫秒那么一毫秒内的生成概率就是 5 个。如果随机数范围是 0~99999理论上同一毫秒内不同机器、不同线程产生相同随机数的概率约为 5 * (1/100000)也就是万分之零点五看起来很低但如果你跑一整天碰撞次数可能会累积到个位数。对于订单号这类数据个位数的碰撞也足够给你添乱了。6.3 引入 Redis 发号器绝对可靠但开销大在压测精度要求极高的场景比如压测分库分表中间件我会在压测环境单独部署一个 Redis用它来做全局唯一发号。脚本里从 Redis 取一个自增值作为唯一标识的一部分。这样绝对不重复但问题也很明显——每次取号都有一次网络往返压测脚本自身的开销变大了。如果被测系统本身允许我更推荐把压测机分组每组分配一段号段区间在脚本本地按号段自增减少对 Redis 的依赖。7. 一场压测的完整唯一标识检查清单照着做就行说了这么多最后我把自己的压测前检查清单整理出来。每次压测之前按这个顺序过一遍基本能拦住 90% 的标识类问题。明确业务语义这个接口到底是用户级、设备级、还是单次请求级的唯一标识先分清再选生成策略。确认格式要求后端有没有格式校验长度、字符集、前缀规则是什么先用少量样本验证。区分线程级和迭代级线程级标识放 setUp 或用户自定义变量迭代级标识放 JSR223 预处理程序每次迭代重新生成。检查是否有静态变量JMeter 变量、CSV 数据、配置元件里的常量逐一排查凡是能在多次迭代之间保持不变的都要确认是不是有意的。分布式压测前核对 workerId每台施压机的隔离因子是否唯一machineId、线程号、时间戳的组合是否经过验证压测中实时监控用聚合报告和日志平台的检索功能看重复率是否超标。压测后数据校验查数据库的 distinct 数量、对日志中的 requestId 做去重统计用最终数据验证脚本设计的正确性。最后再分享一个小技巧压测脚本里生成唯一标识的逻辑一定要允许通过参数开关来切换固定模式和随机模式。固定模式用于功能联调方便复现问题随机模式用于压测执行。这样一次脚本两处复用调试的时候省了我大量的时间。性能测试里唯一标识这件事说大不大说小不小——处理得好它就是数据流中的普通参数处理不好它就是压测结果失真的万恶之源。希望这篇文章能帮你把这块地基打扎实。

性能测试中的唯一标识：从压测事故到JMeter实战方案

相关推荐

Cheat Engine 6.8.1 源码编译与核心模块拆解实战

【单片机毕设案例分享】基于蓝牙的便携式工业粉尘浓度检测报警系统设计基于 WiFi 的储物间温湿度与甲醛远程监测控制系统设计（030121）

给 Claude CLI 装上“长期记忆”：claude-mem 让跨会话开发不再失忆

更多资讯

Java对接华视CVR-100身份证读卡器：JNA动态库调用与GBK解码实践

V3SP3R 功能全景图：12 大核心模块一次看懂，打造你的口袋安全实验室

影刀RPA新手教程：表单自动填写实战——批量录入与动态表单处理

OpenClaw 接入 deepseek 的 Windows 安装全流程攻略：从 PowerShell 到 TaoToken 配置

AI日报｜Anthropic把前沿模型带进工业防御 / Google给Agent独立身份 / 边缘决策模型压到3B

Flarum Tags 扩展功能演进与核心机制解读：从 beta 到 2.x 的标签体系全解析

今日更新

交通拥堵预测毕设：基于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 成本测算与选型避坑（附配置）

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

相关推荐

Cheat Engine 6.8.1 源码编译与核心模块拆解实战

【单片机毕设案例分享】基于蓝牙的便携式工业粉尘浓度检测报警系统设计 基于 WiFi 的储物间温湿度与甲醛远程监测控制系统设计（030121）

给 Claude CLI 装上“长期记忆”：claude-mem 让跨会话开发不再失忆

更多资讯

Java对接华视CVR-100身份证读卡器：JNA动态库调用与GBK解码实践

V3SP3R 功能全景图：12 大核心模块一次看懂，打造你的口袋安全实验室

影刀RPA新手教程：表单自动填写实战——批量录入与动态表单处理

OpenClaw 接入 deepseek 的 Windows 安装全流程攻略：从 PowerShell 到 TaoToken 配置

AI日报｜Anthropic把前沿模型带进工业防御 / Google给Agent独立身份 / 边缘决策模型压到3B

Flarum Tags 扩展功能演进与核心机制解读：从 beta 到 2.x 的标签体系全解析

今日更新

交通拥堵预测毕设：基于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 成本测算与选型避坑（附配置）

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

【单片机毕设案例分享】基于蓝牙的便携式工业粉尘浓度检测报警系统设计基于 WiFi 的储物间温湿度与甲醛远程监测控制系统设计（030121）