429 一来就狂重试：退避时间预算怎么算-北京尧图网络

版权与内容来源声明本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容均在附表 A 中标注来源引用官方原文保持原样不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式也不对任何收益结果作承诺。转载请注明出处。把重试次数从 3 改成 8是很多人撞上 429 之后的第一反应。我在本机把这笔账按时间线求和跑了一遍单次请求上限 2 秒、退避基数 1 秒、退避封顶 20 秒每次失败后等待按倍数拉长最长不超过 20 秒8 次尝试要跑满 87 秒 —— 而配置里那个「总超时 30 秒」早在第 5 次尝试结束时就到期了。后面 3 次不是重试是排队等超时。这篇不算「该重试几次」只算账一次重试循环花掉多少时间、四个参数怎么互相约束、撞到 429 时该看哪个数。一、先分清三块开销重试次数不是答案一次重试循环的总耗时是三块的加和 —— 每次尝试自身占用的时间、退避等待的累计、以及被重试放大的后端负载。只去调「重试次数」这一个旋钮另外两块一定会把它顶回来。三块开销分别是哪些账第一块是尝试开销等于「尝试次数 × 单次请求上限」。这里有个高频率的混淆把单次超时当成了整个操作的上限。OpenAI 的官方限流文档里有一句写得很直白A timeout for each attempt isn’t necessarily a deadline for the entire operation.单次尝试的超时并不必然是整个操作的截止时间。也就是说「每次最多等 2 秒」和「整个调用最多花 30 秒」是两个独立的数很多人只配了前者。第二块是退避等待的累计。指数退避每次等待按倍数拉长的等待序列是几何级数哪怕加了封顶封顶之后每一步仍在持续累加 —— 封顶不是停止只是变成线性增长。第三块不落在你的耗时账上落在对方的配额账上。OpenAI 文档里明确写了Note that unsuccessful requests contribute to your per-minute limit, so continuously resending a request won’t work.失败的请求同样计入你的每分钟限额所以不停地重发是没有用的。换句话说重试不只是「再试一次」它是在消耗配额的同时制造失败。AWS Builders’ Library 把重试直接定性为一句话Retries are “selfish.”—— 它的意思是客户端用服务器更多的时间去换自己更高的成功概率。开销由什么决定只调重试次数会怎样该盯哪个数尝试开销尝试次数 × 单次请求上限次数翻倍尝试开销同步翻倍单次请求上限退避等待累计退避基数、增长倍率、封顶值次数一加等待按几何级数爆掉累计等待时间线后端负载放大单位时间内的重试并发数次数越多二次峰值越高每个时间片的重试请求数为什么次数不能手写重试次数必须是算出来的输出不能是手写进去的输入 —— 它的上游是单次上限、总预算、退避基数、封顶值。二、每次重试要等多久退避公式怎么估闭式公式能给你一个起点但它建立在两个通常不成立的假设上退避序列不被封顶且每次尝试本身不耗时。所以它只能当首轮估算必须用时间线求和回头验算。闭式给的是上界不是答案先看闭式。退避基数记作 W、倍率记作 rn 次重试的等待之和是 W(r^n − 1)/(r − 1)。让它不超过总预算 B解出可重试次数 n ≈ floor( log_r( 1 - B × (1 - r) / W ) )。代入 B 30 秒、W 1 秒、r 2得 n ≈ 4这就是那类「30 秒预算够重试 4 次」的估算来源。但完整的账要把每次尝试自身的开销也放进去n × 单次请求上限 W(r^n − 1)/(r − 1) ≤ B且每一项等待还要被封顶值截断。时间线求和怎么验算这两个式子必须联立解单独满足任何一个都会失效。我用时间线求和验算了一遍差距是真实存在的实测环境Python 3.13.12 / macOS / 仅用标准库 random、math / 脚本 work/exp1014/exp02a.py下列可独立运行importmath,random T_REQ,BUDGET,MAX_ATTEMPTS,BASE,CAP,SEED2.0,30.0,8,1.0,20.0,20261014defwaits_fixed(n):return[BASE]*ndefwaits_exp(n):return[min(CAP,BASE*(2**i))foriinrange(n)]defwaits_jitter(n,rng):return[rng.uniform(0,min(CAP,BASE*(2**i)))foriinrange(n)]deftimeline(waits):# 第 n 次尝试结束时刻 n*T_req 前 n-1 次等待之和ends[round((i2)*T_REQsum(waits[:i1]),3)foriinrange(len(waits))]returnendsor[round(T_REQ,3)],(endsor[T_REQ])[-1]defattempts_within(waits):elapsed,doneT_REQ,1ifT_REQBUDGETelse0forwinwaits:elapsedwT_REQifelapsedBUDGET:done1else:breakreturndonedefclosed_form(b,w0,r):# 只算退避等待不含单次开销inner1.0-b*(1.0-r)/w0returnint(math.floor(math.log(inner,r)))ifinner0elseNonedefsummed(b,tT_REQ,w0BASE,capCAP,r2.0):# 时间线求和口径elapsed,nt,0whileTrue:wmin(cap,w0*(r**n))ifelapsedwtb:breakelapsedwt;n1returnn,round(elapsed,3)rng,n_retryrandom.Random(SEED),MAX_ATTEMPTS-1forname,waitsin[(固定间隔 1s,waits_fixed(n_retry)),(指数退避基数1s(截断20s),waits_exp(n_retry)),(指数full jitter(截断20s),waits_jitter(n_retry,rng))]:ends,totaltimeline(waits)print(f---{name}---)print( 等待序列(s) : , .join(f{w:.3f}forwinwaits))print( 尝试结束时刻: , .join(f{e:.3f}foreinends))print(f 累计总耗时 :{total:.3f}s)print(f 预算内实际完成尝试次数:{attempts_within(waits)}/{MAX_ATTEMPTS})print()print(f闭式(只算退避等待, 不含单次开销) 可重试次数 ≈{closed_form(BUDGET,BASE,2.0)})print(f时间线求和(含单次{T_REQ}s 开销) 指数退避实际完成尝试次数 {attempts_within(waits_exp(n_retry))})print()print(f{总预算B(s):10}|{闭式可重试次数:14}|{求和可重试次数:14}|{含单次开销的耗时(s):18})print(-*66)forbin(10.0,20.0,30.0,60.0,120.0):est,(real,used)closed_form(b,BASE,2.0),summed(b)print(f{b:10.1f}|{str(est):14}|{real:14}|{used:18.3f}(ifestrealelse -- 两个口径分叉))原样输出同一组参数--- 固定间隔 1s --- 等待序列(s) : 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000 尝试结束时刻: 5.000, 8.000, 11.000, 14.000, 17.000, 20.000, 23.000 累计总耗时 : 23.000s 预算内实际完成尝试次数: 8 / 8 --- 指数退避基数1s(截断20s) --- 等待序列(s) : 1.000, 2.000, 4.000, 8.000, 16.000, 20.000, 20.000 尝试结束时刻: 5.000, 9.000, 15.000, 25.000, 43.000, 65.000, 87.000 累计总耗时 : 87.000s 预算内实际完成尝试次数: 5 / 8 --- 指数full jitter(截断20s) --- 等待序列(s) : 0.728, 0.350, 3.073, 6.459, 9.457, 6.615, 7.159 尝试结束时刻: 4.728, 7.077, 12.150, 20.609, 32.065, 40.680, 49.839 累计总耗时 : 49.839s 预算内实际完成尝试次数: 5 / 8 闭式(只算退避等待, 不含单次开销) 可重试次数 ≈ 4 时间线求和(含单次 2.0s 开销) 指数退避实际完成尝试次数 5 总预算B(s) | 闭式可重试次数 | 求和可重试次数 | 含单次开销的耗时(s) ------------------------------------------------------------------ 10.0 | 3 | 2 | 9.000 -- 两个口径分叉 20.0 | 4 | 3 | 15.000 -- 两个口径分叉 30.0 | 4 | 4 | 25.000 60.0 | 5 | 5 | 43.000 120.0 | 6 | 8 | 109.000 -- 两个口径分叉三个能直接拿走的读数。闭式给出的 4 次重试对应 5 次尝试和时间线求和正好对得上但预算挪到 10 秒、20 秒、120 秒三个档位全部分叉方向还不一致 —— 前两档闭式偏乐观120 秒那档偏悲观封顶拉长了线性段闭式假设的是不封顶的几何级数。指数退避在 30 秒预算内只跑得完 5 次尝试配置里写 8 次有 3 次白等。加抖动让同样的 8 次尝试从 87 秒缩到 49.8 秒。三、三档方案固定间隔 / 指数退避 / 指数加抖动只有「指数抖动」能同时压住总耗时和二次峰值固定间隔在限流持续时会把自己的重试打成一条稳定的高负载纯指数退避则会把所有客户端对齐到同一时刻。固定间隔与纯指数退避各缺什么策略前 4 次等待序列30 秒预算内完成跑满 8 次耗时主要代价固定间隔 1s1, 1, 1, 18 次23s限流持续时重试变成稳定负载指数退避基数 1s封顶 20s1, 2, 4, 85 次87s客户端同步重试形成二次峰值指数 full jitter同参数0.73, 0.35, 3.07, 6.465 次49.8s需要随机源与可复现种子三档里最容易被低估的是纯指数退避。AWS Builders’ Library 指出了它的两个坑一是封顶之后Now all of the clients are retrying constantly at the capped rate.所有客户端都以封顶速率不停重试二是没有抖动时If all the failed calls back off to the same time, they cause contention or overload again when they are retried.失败的调用都退避到同一时刻重试时会再次造成竞争或过载。这就是「惊群」大量客户端退避到同一时刻、一起重试的工程后果 —— 抖动不是调优项是防二次峰值的必需项。抖动把峰值摊平我把这个峰值量化跑了一遍实测环境Python 3.13.12 / macOS / 仅用标准库 random / 固定种子 20261014 / 脚本 work/exp1014/exp02b.py下列可独立运行importrandom N_CLIENTS,MAX_RETRY,BASE,CAP,BUCKET,WINDOW,SEED200,6,1.0,60.0,0.1,70.0,20261014defretry_times(jitter,rng):# 200 个客户端各自的重试时刻t0 是首次被限流时刻per_client[]for_inrange(N_CLIENTS):t,times0.0,[]foriinrange(MAX_RETRY):uppermin(CAP,BASE*(2**i))trng.uniform(0.0,upper)ifjitterelseupper# full jitterU(0, upper)times.append(t)per_client.append(times)returnper_clientdefbucketize(per_client):# 按 0.1 秒时间片统计重试请求数nint(WINDOW/BUCKET)1counts[0]*nfortimesinper_client:fortintimes:idxint(t/BUCKET)ifidxn:counts[idx]1returncountsdefrender(name,counts):peakmax(counts)peak_at[round(i*BUCKET,1)fori,cinenumerate(counts)ifcpeak]nonzero[cforcincountsifc0]meansum(counts)/len(counts)print(f---{name}---)print(f 重试请求总数 :{sum(counts)})print(f 单时间片峰值 :{peak}出现在 t {peak_at}s)print(f 峰值/均值比 :{peak/mean:.1f}x 均值{mean:.2f}次/片)print(f 空时间片占比 :{1-len(nonzero)/len(counts):.1%}f有请求的时间片{len(nonzero)}/{len(counts)})returnpeak cabucketize(retry_times(False,random.Random(SEED)))peak_arender(无抖动纯指数退避,ca)print()cbbucketize(retry_times(True,random.Random(SEED)))peak_brender(有抖动full jitter,cb)print()print(f无抖动峰值单时间片请求数 :{peak_a})print(f有抖动峰值单时间片请求数 :{peak_b})print(f峰值下降倍数 :{peak_a/peak_b:.2f}x)print(f总请求数两种策略相同 :{sum(ca)}vs{sum(cb)})原样输出--- 无抖动纯指数退避 --- 重试请求总数 : 1200 单时间片峰值 : 200 出现在 t [1.0, 3.0, 7.0, 15.0, 31.0, 63.0] s 峰值/均值比 : 116.8x 均值 1.71 次/片空时间片占比 : 99.1% 有请求的时间片 6/701 --- 有抖动full jitter --- 重试请求总数 : 1200 单时间片峰值 : 43 出现在 t [0.9] s 峰值/均值比 : 25.1x 均值 1.71 次/片空时间片占比 : 52.8% 有请求的时间片 331/701 无抖动峰值单时间片请求数 : 200 有抖动峰值单时间片请求数 : 43 峰值下降倍数 : 4.65x 总请求数两种策略相同 : 1200 vs 1200200 个客户端在 t0 同时被限流两种策略的总重试请求数完全一样1200 次差别只在落点无抖动时全部砸在 t1.0、3.0、7.0、15.0、31.0、63.0 这六个瞬时点上单时间片峰值 200加抖动后同样的 1200 次请求被摊到 331 个时间片上峰值 43 次空时间片占比从 99.1% 降到 52.8%。峰值差 4.65 倍代价是零 —— 只是把固定等待换成U(0, 上界)。AWS 架构博客用 100 个竞争客户端做过同类模拟结论一致In the case with 100 contending clients, we’ve reduced our call count by more than half.在 100 个竞争客户端的情况下我们把调用次数减少了一半以上。四、把总时间预算跑成一段代码预算不是「最坏情况下愿意等多久」它必须反过来约束尝试次数。把「单次请求上限、总时间预算、最大重试次数、退避基数含封顶与抖动」放进同一个函数让尝试次数成为输出账才算闭环。四个参数怎么联立实测环境Python 3.13.12 / macOS / 仅用标准库 random / 脚本 work/exp1014/exp02c.pydefplan(budget,t_req2.0,base1.0,cap20.0,r2.0,max_attempts8):used,done,nt_req,1,0# 首次尝试也占一个 t_reqwhilenmax_attempts:wmin(cap,base*r**n)# 不抖动的上界最坏情况ifusedwt_reqbudget:breakusedwt_req;n1;done1returndone,round(used,3)defbudget_needed(n_attempts,t_req2.0,base1.0,cap20.0,r2.0):waits[min(cap,base*r**i)foriinrange(n_attempts-1)]# 首次之前无等待returnround(n_attempts*t_reqsum(waits),3)forbin(10.0,20.0,30.0,60.0,90.0):print(预算,b,→ 实际可用,plan(b)[0],次尝试)print(要跑满 8 次尝试需要预算,budget_needed(8),s)同一个脚本的原样输出数字未改动预算 10 秒 → 实际可用 3 次尝试20 秒 → 4 次30 秒 → 5 次60 秒 → 6 次90 秒 → 8 次要跑满 8 次尝试需要预算 87.0 秒。注意末行要 8 次尝试就得准备 87 秒预算而常见配置里的操作总超时是 30 秒级别 —— 差了三倍。要么把次数降到预算装得下的档位要么把预算提上去不能两个都不动。参数取值与联立约束参数含义取值建议依据配置错方向会怎样单次请求上限一次尝试最多占多久取下游 p99.9 延迟按可接受的误超时比例反推AWS 是先从下游延迟分位数起手设太小慢请求被判失败并重试反而放大负载总时间预算从首次发起到放弃不超过调用方给你的 deadline留出收尾余量OpenAI单次超时不是整个操作的上限设太大失败感知慢设太小重试没机会最大重试次数含首次的尝试上限取联立式解出的 n本文 exp02a / exp02c 实测手写 8 次30 秒预算下 3 次白等退避基数首次等待时长0.5 到 1.0 秒封顶在 20 秒量级urllib3 源码文档的生产建议setting a non-zero factor (e.g. 0.5 to 1.0)基数太大前两次就把预算烧完urllib3 的默认策略可以直接当参照系它的重试睡眠是{backoff factor} * (2 ** ({number of previous retries}))默认封顶值是 120 秒默认退避因子是 0 —— 也就是说默认不重试要用得自己显式打开。这份资料里有什么四个参数怎么联立、以及怎么把重试账算成一段能跑的代码涉及的超时与退避基础概念比较多。相关的概念梳理和排障清单放在资料包里扫码即可获取五、按现象排障撞上限流时该看哪个数撞上 429 之后的第一反应不该是调大重试次数而是先分清是哪一类现象每类现象只对应一个要看的数。四类现象各对应一个参数现象最可能的原因该看的数处置一直失败重试也没成功总预算太小重试被砍在半路预算内实际可完成的尝试次数先把预算提到能容纳目标次数失败得更快比不加重试还差抖动缺失多客户端同步重试形成二次峰值失败请求也在吃配额每个时间片的重试请求数给退避加 full jitter失败请求按配额定速而不是无条件重发偶尔成功整体不稳退避基数太大前两次就把预算烧完首次等待与累计等待时间线基数降到 0.5 到 1.0 秒或把重试整体转成排队延迟尾部长并发重试路数过高尾请求被自己的重试叠加拉长并发重试路数、单次上限限制并发重试路数尾延迟按整个操作统计第二行值得单说。失败的请求同样计入每分钟限额所以不停重发不会更好 —— 重试本身就在消耗你被允许的额度抖动缺失时这层消耗会以峰值形式集中释放。第三行的「偶尔成功」最容易被误判成「重试有效」。它其实是基数太大叠加预算太小预算只够跑两三次第一次成功靠运气后面全在等超时。可以直接落地的两条纪律第一手建议里有两条可以直接当配置纪律。一条来自 OpenAI 官方文档Treat this value as a minimum: wait at least that long and add a small random delay so multiple clients don’t retry at the same time.把 Retry-After 当作最小值至少等这么久再加一个小随机延迟避免多个客户端同时重试。另一条来自 urllib3 源码里的幂等方法白名单同一请求发多次、服务端效果与发一次相同DEFAULT_ALLOWED_METHODS frozenset([HEAD, GET, PUT, DELETE, OPTIONS, TRACE])注释写明By default, we only retry on methods which are considered to be idempotent。注意这个列表里没有 POST。六、什么时候该停下重试、交给队列有三种情况必须停止自动重试操作不幂等、退避已打满封顶且依赖没恢复迹象、重试预算会吃穿你自己的 deadline。非幂等是硬约束第一种是硬约束不是调优建议。RFC 9110 第 9.2.2 节给幂等下的定义是A request method is considered idempotent if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.幂等的含义是对同一方法发出的多个相同请求服务端产生的预期效果与单个请求相同本规范定义的方法里PUT、DELETE 与安全方法幂等。同一节还写了两条规范性要求A client SHOULD NOT automatically retry a request with a non-idempotent method unless ...非幂等方法的请求不应自动重试除非能确认语义实际幂等或能检测到原请求从未生效以及A proxy MUST NOT automatically retry non-idempotent requests. A client SHOULD NOT automatically retry a failed automatic retry.代理不得自动重试非幂等请求客户端不应自动重试一次已失败的自动重试。末了那半句很容易被忽略重试失败后的重试也不行。很多重试库默认允许这种嵌套重试叠起来就是指数级的请求量。AWS 的口径是把重试当成需要观察才能维持的动作We avoid this amplification by retrying only when we observe that the dependency is healthy. We stop retrying when the retries are not helping to improve availability.只在下游健康时重试重试不再提升可用性时就停止。它给出的停手判据是「看它有没有变好」而不是「看我还剩几次」。什么时候转队列落到可执行的阈值上我给三个非幂等的写操作典型是 POST 创建类接口不做自动重试改成先查后写或带幂等键。urllib3 的白名单可以直接照抄。预算内可完成尝试次数 ≤ 2时不要配重试。按本文实测30 秒预算配 2 秒单次上限只够 5 次尝试预算压到 10 秒只剩 3 次 —— 这种量级没有统计意义。并发重试路数超过 8就改走队列请求先落队列由固定速率的消费端慢慢取失败进死信。阈值取 8 的理由是超过这个数重试产生的并发本身就会把下游从「部分失败」推向「完全不可用」。配置的落点就是四个数加一个开关max_attempts: 4含首次由预算反解得出不手写、single_timeout_s: 2.0、total_budget_s: 30.0、退避的base_s: 1.0与cap_s: 20.0、jitter: full再加一个「并发重试路数超过 8 就转队列」的兜底开关。这四条合起来只说明一件事重试次数是算出来的不是配出来的。先定单次上限和总预算再解出次数用抖动把峰值摊平任何一步单独调账都会从另一头破掉。这份资料里有什么文中用到的重试时间线脚本、官方超时与退避建议的对照汇总都在这一份里涉及的概念比正文更细。放在资料包里扫码即可获取附表 A本文引用事实与出处对照表#事实出处本文位置1「重试是自私的」「封顶后所有客户端以封顶速率不停重试」「失败的调用退避到同一时刻会再次造成竞争或过载」「只在下游健康时重试」AWS Builders’ Library《Timeouts, retries, and backoff with jitter》aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/取数日期 2026-10-14第一章、第三章、第六章2「100 个竞争客户端下调用次数减少一半以上」抖动把尖刺摊成近似恒定速率AWS Architecture Blog《Exponential Backoff And Jitter》aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/取数日期 2026-10-14第三章3幂等方法定义客户端不应自动重试非幂等请求代理不得自动重试非幂等请求不应自动重试已失败的自动重试RFC 9110《HTTP Semantics》第 9.2.2 节 Idempotent Methodsrfc-editor.org/rfc/rfc9110.txt取数日期 2026-10-14第六章4默认只对幂等方法重试退避睡眠公式与默认封顶 120 秒默认退避因子 0生产环境建议 0.5 到 1.0 并配合 backoff_jitterurllib3 源码src/urllib3/util/retry.pymain 分支取数日期 2026-10-14urllib3.readthedocs.io 参考页第四章、第五章5把 Retry-After 视为最小值并加随机延迟失败请求计入每分钟限额单次超时不等于整个操作的截止时间退避缺失时回落到带抖动的指数退避OpenAI《Rate limits》官方文档developers.openai.com/api/docs/guides/rate-limits取数日期 2026-10-14第一章、第五章6三种退避策略在「单次上限 2 秒 / 总预算 30 秒 / 最大 8 次尝试」下的时间线与总耗时闭式与求和的口径分叉本文实测脚本 work/exp1014/exp02a.py输出 exp02a_out.txt2026-10-14 运行第二章7200 客户端同步重试时无抖动与有抖动的单时间片峰值对比200 对 43本文实测脚本 work/exp1014/exp02b.py输出 exp02b_out.txt2026-10-14 运行种子 20261014第三章8四个参数联立后反解的实际可用尝试次数跑满 8 次尝试所需预算为 87 秒本文实测脚本 work/exp1014/exp02c.py输出 exp02c_out.txt2026-10-14 运行第四章写在最后这篇用到的资料写这篇文章时把相关的官方文档和源码又翻了一遍顺手也整理了几份配套的东西大模型学习路线图从零基础到能自己动手做 Agent按阶段说明每一步该学什么、哪些可以先跳过《LangChain LangGraph MCP 智能体开发实战》视频课7 个模块从私有化部署、EmbeddingRAG 到 MCPAgent 全流程AI 大模型知识库在线可查Agent Skills 从入门到落地、Claude Skills 完全指南等专题按目录浏览即可640 套 AI 大模型行业报告经典 PDF 书籍看行业落地案例和别人怎么做的时候用得上大模型零基础到精通教学视频跟着敲一遍比只读文档快得多资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「AI」优先通过。资料按「先路线、再动手、最后查漏」的顺序整理好了建议先看学习路线那一份照着它挑一条适合自己当前基础的路径再往下看。

429 一来就狂重试：退避时间预算怎么算

相关推荐

两万星标AI编程教程：项目驱动与实战踩坑经验分享

JSP房产中介管理系统部署实战：从环境搭建到二次开发全流程解析

基于SpringBoot的在线诊疗管理系统设计与实现全流程指南

更多资讯

浏览器插件ponytail：技能包机制与网页信息自动化整理

企业环保评价报告全流程指南与实战技巧

FanControl 识别不到风扇：3 项快查 + 4 层定位，把转速找回来

ponytail物理模拟技术原理与动画应用

OpenHarmony与React Native集成中Redux异步Action的解决方案

微信聊天记录导出工具：SQLite解析与多格式导出实战

今日更新

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

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

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

本周精选

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

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

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

本月热门

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

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

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

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