秒杀系统高并发架构：Redis限流与库存扣减实战解析-北京尧图网络

1. 项目背景与总体架构设计1.1 业务规模与核心挑战先把这个项目的背景讲清楚。这是一个电商平台的模拟大促秒杀项目商品数量 20 万预约用户规模 100 万目标峰值对外宣称百万 QPS。乍一听“百万 QPS”挺吓人但经历过几次大促的人都知道真正落到后端写链路的高并发请求通常远低于这个数关键在于怎么在各个入口把流量削平、过滤、分流而不是让所有请求都打穿到数据库。秒杀场景下最头疼的其实是三个问题第一瞬时流量极高开始抢购的那几秒是最高峰如果所有用户同时点按钮请求洪峰能把任何单机服务冲垮第二库存扣减必须保证不超卖也不少卖20 万件商品的库存分散在若干缓存节点和数据库分表里任何一步出现并发竞态都会造成资损第三前后端都要配合前端不能重复提交后端不能重复下单用户 100 万预约的资格校验还要在秒杀开启瞬间扛住大量读请求。所以这个项目的设计核心不是“把所有请求都处理完”而是在“尽量少的关键请求”上做到极致的可靠。换句话说秒杀系统本质上是一个流量控制工程而不是一个普通 CRUD 工程。1.2 分层架构与技术选型项目的总体架构可以简单划分成四层接入层、应用层、缓存层、存储层。接入层负责静态资源分发和网络层限流应用层跑核心业务逻辑缓存层存放库存和预约资格存储层最终落库订单和流水。这样的分层能保证每一层都有独立的扩展能力不至于因为某一层的瓶颈拖垮整条链路。技术选型方面应用层用了常用的 Spring Boot 微服务框架缓存层使用 Redis Cluster配置中心在 Apollo 和 Nacos 之间做了选型数据库采用 MySQL 主从加商品分表。为什么不用单机 Redis20 万商品如果集中在一两个 Redis 节点上内存和热点会非常集中秒杀时一个热 Key 就能把单节点 CPU 打满。Redis Cluster 的好处是数据可以按照 slot 分散到多台机器天然规避单点压力。存储层看上去简单但秒杀订单不能直接落到普通业务表而是先通过消息队列异步落库再加上分表策略。异步落库可以缩短核心链路响应时间分表则避免单表数据量过大。整个过程总结下来就是尽量把流量挡在前面让真正进入核心链路的请求少而精。2. 前端交互与预约链路设计2.1 静态资源托管与 CDN 加速很多人容易忽略前端在秒杀体系里的重要性。100 万预约用户同时刷秒杀页如果页面上的商品数据、图片、脚本都从应用服务器出单靠后端扛是扛不住的。这个项目的做法是秒杀页面在活动开始前就预生成好静态 HTML上传到 CDN用户在客户端请求时直接命中就近的 CDN 节点应用服务器完全不感知。页面上的动态数据要尽量少。比如倒计时通常由一个接口返回活动开始时间前端拿到时间后本地做倒计时而不是每秒轮询服务器。商品展示列表做成静态化快照活动期间不允许运营随意改商品文案避免页面缓存失效。静态资源域名和应用接口域名分开也有讲究。静态域名不会携带 Cookie请求体积小CDN 命中率高接口域名单独配置跨域和安全策略方便排查问题。还有一个细节静态资源要设置较长的浏览器缓存时间这样秒杀开始后用户刷新页面时浏览器本地直接命中不会产生额外请求。2.2 预约流程与资格校验预约功能和普通“报名”不太一样需要做到两件事一是记录 100 万用户的预约关系二是秒杀开启时快速判断某个用户是否有资格。100 万条数据如果在数据库里直接做存在性判断秒杀瞬间数据库会被读请求打爆。所以预约数据在写库的同时还要同步写入 Redis。典型做法是用 Redis 的 Set 数据结构存储预约用户 IDKey 格式类似reserve:users:{goodsId}。写入的时候利用SADD天然去重的特性重复预约不会产生脏数据。示例代码如下public boolean addReserve(Long userId, Long goodsId) { String key reserve:users: goodsId; Long rst stringRedisTemplate.opsForSet().add(key, String.valueOf(userId)); if (rst ! null rst 0) { // 异步发送预约成功消息用于后续短信通知和数据库落库 mqSender.send(reserve-topic, userId _ goodsId); return true; } return false; }100 万用户放进一个 Set 会导致这个 Key 非常大后续读取和扩容都比较麻烦。实际项目中我把预约用户按照用户 ID 做了取模拆分比如拆成 128 个分片 Keyreserve:users:{goodsId}:{userId % 128}。这样单 Key 数据量控制在几千左右秒杀开始后资格校验的压力也被均匀分散到了 Redis 集群的多个 slot 上。资格校验的接口同样要设置限流。用户进入结算页时会调用checkReserve后端只做一次SISMEMBER判断如果用户没有预约直接返回“未预约”把大量无效请求挡在业务逻辑之前。这里还要注意校验接口一定要加上用户维度限流防止有人拿脚本疯狂遍历用户 ID。2.3 前端防抖与异步结果通知秒杀按钮几乎一定会被用户疯狂点击。前端要做两件事第一秒杀开始前按钮置灰开始瞬间恢复第二用户点击后按钮立即进入“处理中”状态短时间内不可重复点击。这听起来很简单但很多项目都栽在“按钮置灰”只做了前端校验抓包后仍然可以绕过按钮直接发请求。所以前端防抖只是用户体验层面的第一道闸门真正防重复提交还要靠后端。用户每次点击提交请求时后端会先把用户 ID、商品 ID、活动批次号拼接成一个唯一请求流水号使用 RedisSETNX加 10 秒过期时间做幂等同一个用户同一商品在短暂时间内只能创建一个订单流水。这个设计方案非常适合秒杀场景简单又有效。秒杀请求提交成功后不建议给用户同步返回订单结果因为核心链路还要做库存扣减、资格核销、异步下单等操作同步等待会导致接口耗时过长。项目里前端提交后返回“已受理”然后通过轮询或者长连接查询用户维度的订单状态。轮询本身也要注意频率每次轮询间隔不少于 2 秒并且有个最大轮询次数超过次数后提示用户刷新页面。3. 基于 RedisLua 的分布式令牌桶限流3.1 令牌桶与漏桶的取舍限流是秒杀系统的灵魂。项目里在网关和应用层都设置了限流核心算法选择了令牌桶而不是漏桶。很多初学者会问为什么不直接固定速率放行因为秒杀场景有一个特殊性用户点击行为往往集中在开始后的前 10 秒完全匀速放行会积压大量超时请求用户体验极差令牌桶允许一定程度的突发流量只要桶里还有令牌短时间内可以放行比平均速率更多的请求这对业务来说更合理。漏桶更像是“恒定速率管道”无论上游多猛下游都只能以固定速度处理令牌桶则可以控制“每秒新增多少个令牌”让系统在突发和稳定之间找到一个平衡点。当然这里有一个前提令牌桶里的令牌数量不是随便拍的。活动商品总量是 20 万如果我希望订单在 5 分钟内消化完那么每秒至少要放行 200000 / 300 ≈ 667 个请求再算上客户端重试、网络抖动等因素可以设置每秒 1000 个令牌桶容量 5000。这个参数不能拍脑袋一定要根据库存总量和预估售卖时长倒推。3.2 基于 RedisLua 的实现单机限流用 Guava 的 RateLimiter 很容易但项目是分布式部署多个应用节点各自限流会导致整体流量不可控所以必须用 Redis 做一个集中式的令牌桶。实现方式上不建议用先读取再写入的方式因为并发场景下会产生竞态条件。最稳妥的办法是把令牌桶逻辑写进 Lua 脚本利用 Redis 单线程执行 Lua 的特性来保证原子性。下面这段 Lua 脚本就是项目里实际使用的令牌桶核心逻辑-- KEYS[1]: 限流 key -- ARGV[1]: 当前时间戳秒 -- ARGV[2]: 初始令牌数 -- ARGV[3]: 每秒补充令牌数 -- ARGV[4]: 桶容量 local last_time tonumber(redis.call(HGET, KEYS[1], last_time) or ARGV[1]) local tokens tonumber(redis.call(HGET, KEYS[1], tokens) or ARGV[2]) local now tonumber(ARGV[1]) local rate tonumber(ARGV[3]) local capacity tonumber(ARGV[4]) local delta math.max(0, now - last_time) * rate tokens math.min(capacity, tokens delta) if tokens 1 then redis.call(HSET, KEYS[1], last_time, now) redis.call(HSET, KEYS[1], tokens, tokens - 1) return 1 else redis.call(HSET, KEYS[1], last_time, now) redis.call(HSET, KEYS[1], tokens, tokens) return 0 endJava 侧调用时通过 RedisTemplate 执行这段 Lua 脚本private static final String RATELIMIT_LUA local last_timetonumber(redis.call(HGET,KEYS[1],last_time) or ARGV[1]) local tokenstonumber(redis.call(HGET,KEYS[1],tokens) or ARGV[2]) local nowtonumber(ARGV[1]) local ratetonumber(ARGV[3]) local capacitytonumber(ARGV[4]) local deltamath.max(0,(now-last_time))*rate tokensmath.min(capacity,tokensdelta) if tokens1 then redis.call(HSET,KEYS[1],last_time,now) redis.call(HSET,KEYS[1],tokens,tokens-1) return 1 else redis.call(HSET,KEYS[1],last_time,now) redis.call(HSET,KEYS[1],tokens,tokens) return 0 end; public boolean tryAcquire(String key, int rate, int capacity) { long now System.currentTimeMillis() / 1000; DefaultRedisScriptLong script new DefaultRedisScript(RATELIMIT_LUA, Long.class); ListString keys Collections.singletonList(key); Long rst redisTemplate.execute(script, keys, String.valueOf(now), String.valueOf(capacity), String.valueOf(rate), String.valueOf(capacity)); return rst ! null rst 1L; }这里的HGET和HSET选择 Hash 结构是为了把上次补充时间和当前令牌数放在同一个 Key 下后续扩容或者排查数据都方便。还需要特别注意限流 Key 的分布。如果所有请求都打在同一把 Key 上Redis 实例上仍然会形成一个热点 Key。项目里的做法是按照用户 ID 取模比如ratelimit:user:{userId % 256}这样负载相对均匀对于商品维度则按照商品 ID 取模分片。3.3 多级限流与流量调度限定一个地方还不够。网关层和业务层要做不同粒度的限流。网关层通常配置 IP 维度限流和全局总流量限流防止某个恶意 IP 发起超大规模请求业务层则配置用户维度限流和商品维度限流。举个例子如果网关层限定全局入口最多 50 万 QPS但某个商品的热度过高所有请求都集中在同一个商品上商品服务的压力依然很大。所以业务层还要针对每个秒杀商品单独配置令牌桶每个商品每秒最多放行 1000 个请求超过部分直接返回“活动太火爆”。这两级限流配合起来既保护了整个系统也保护了单个商品的数据节点。多级限流参数必须支持动态调整这就是配置中心发挥作用的地方。活动开始前运营可以按预估流量设置一个比较保守的值如果实际流量低于预期可以动态调高限流阈值如果流量过于异常又可以瞬间调低实现“宽进严出”的弹性控制。4. 商品分片与 Redis 数据布局4.1 商品分片策略与一致性哈希20 万商品全部放在 Redis 里按商品 ID 作为 Key单节点内存会非常大而且部分热销商品的访问频率远高于普通商品。项目在 Redis Cluster 基础上还在应用层做了一层商品分片逻辑。最简单的方式是对商品 ID 做取模例如goodsId % 128得到分片编号后把库存、预约、限流等数据都落在对应的分片 Key 上。这样做的本质是把一个大 Key 拆成多个小 Key避免单个 Key 的访问量过大。实际操作中我使用的是带权重的一致性哈希环而不是简单的取模。原因是有部分商品可能属于重点运营商品需要占用更多 Redis 节点另一些冷门商品的访问量较少可以共享分片。一致性哈希比起取模更容易做节点扩缩容时的数据迁移当 Redis 集群增加节点时只需要迁移少量 Key不会出现大量缓存失效。代码实现上并不复杂关键是维护好商品 ID 到分片路由的映射关系。项目里这个映射关系不是写死在代码里的而是存储在配置中心后续如果要调整某个商品的分片策略可以直接动态下发不需要重启服务。4.2 库存预加载与热点 Key 拆分秒杀当天最怕的一件事是 Redis 里没有库存数据请求穿透到数据库。项目在活动开始前有一个预热任务定时从数据库把商品库存同步到 RedisKey 定义为seckill:stock:{goodsId}Value 为剩余库存数并设置一个较长的过期时间防止活动过程中内存不足被清理。热销商品即便只有一个 Key仍然会出现单 Key 访问量过于集中的问题。假设一个商品的库存是 1 万件1 秒内 20 万请求都来抢这一个 KeyRedis 单线程执行命令也会有瓶颈。项目里把这个热点商品的库存拆分成多个子 Key例如seckill:stock:1024:0、seckill:stock:1024:1最多拆到 16 个子 Key。扣减库存时用一个 Lua 脚本轮询这些子 Key找到第一个库存大于 0 的分片执行扣减。这样一个商品的访问负载就被分散到多个 Redis slot 上。需要提醒的是库存分片数不能设置得过大否则每个分片的库存余量是很小数值容易出现某个分片提前耗尽而另一个分片还有很多库存的情况。实际项目中我一般把每个分片的库存控制在 500 到 1000 件左右确保不会被某个分片提前清空。4.3 预约用户名单与资格缓存预约数据除了 Set 结构存放用户 ID 外秒杀开启时还需要一个快速判断用户是否有资格的方式。直接把 100 万用户全部缓存为单个 Key无论是内存占用还是查询性能都不划算所以依旧采用分片方式把用户 ID 分散到 128 个分片中。秒杀开始时资格校验接口会变成这样public boolean checkReserve(Long userId, Long goodsId) { int shard (int) (userId % 128); String key reserve:users: goodsId : shard; return stringRedisTemplate.opsForSet().isMember(key, String.valueOf(userId)); }这里还有一个隐藏的优化点资格校验的结果可以做一层本地缓存比如用户第一次校验通过后JVM 本地缓存记录下来有效期几秒。这样同一个用户短时间内多次请求不会反复访问 RedisRedis 的读压力会明显降低。预警名单和黑名单功能也建议做成缓存 Key黑名单用户的特征就是请求频率极高一旦命中标记为黑名单秒杀期间直接返回“账号异常”。这一层可以挡住大部分机器脚本流量。5. 分布式锁与库存扣减的正确姿势5.1 分布式锁选型与 Redisson 实践库存扣减是秒杀系统里最容易出错的地方。很多初学者会直接用数据库的UPDATE stock SET stock stock - 1 WHERE goods_id ?在秒杀场景下这把数据库行锁的竞争会非常严重系统的吞吐量会被拖垮。所以这个项目的库存扣减没有放在数据库而是放在 Redis 内存中完成数据库只是在异步下单时做最终校验。那分布式锁到底用在哪儿应用层多节点同时扣减库存时如果只靠 RedisDECR命令其实已经能保证原子性并不需要额外的锁。分布式锁主要用在一些包含多步操作的场景比如先检查用户资格再扣减库存再记录购买记录这三步如果分成三个命令连续执行中途可能被其他线程插入就需要用锁来保证整体原子性。项目里选用 Redisson 分布式锁因为它提供看门狗机制可以自动续期避免了锁过期后业务还没执行完的尴尬问题。示例代码如下RLock lock redisson.getLock(seckill:lock: goodsId); boolean locked null; try { locked lock.tryLock(0, 30, TimeUnit.SECONDS); if (!locked) { return 活动太火爆请稍后再试; } // 执行资格校验、库存扣减、幂等记录写入 } finally { if (locked lock.isHeldByCurrentThread()) { lock.unlock(); } }这里锁的粒度是按商品 ID 维度不是按用户 ID 维度。如果按用户 ID 加锁同一商品的大量并发请求会分散在不同锁上扣库存时依然存在竞争意义不大按商品 ID 加锁可以保证同一个商品的扣减流程是串行的逻辑简单清晰。5.2 基于 Lua 的原子库存扣减有了锁之后还要考虑一个问题锁只是保证单商品扣减流程串行但如果你有多个商品分片锁还会带来额外的等待开销影响吞吐量。更优的做法是直接把库存扣减设计成一个原子操作不需要锁也能保证不超卖。项目里用 Lua 脚本扣减库存local stock tonumber(redis.call(GET, KEYS[1])) if stock nil then return -1 end if stock 0 then return 0 end redis.call(DECR, KEYS[1]) return 1这段脚本在 Redis 内是原子执行的同一时刻即使有多个线程并发调用也不会出现同时扣成负数的情况。扣减成功之后再发送一条消息到 MQ由消息消费者去创建订单。李姐要注意仅仅扣减 Redis 库存还不够消费者创建订单时极有可能因为数据库主键冲突、用户重复下单等原因失败。如果失败必须把 Redis 库存加回来否则会出现“少卖”的情况。项目里消费者处理流程图是这样的收到消息 - 幂等校验 - 创建订单 - 成功后通知前端创建订单失败 - 发送“库存回补”消息 - RedisINCR回补库存。5.3 事务边界与最终一致性分布式事务在秒杀场景下不能过度依赖强一致。为什么秒杀链路中的 Redis 库存、数据库订单、用户资格记录分布在多个系统中如果全部要求强一致系统的可用性会大打折扣。所以项目采用的是最终一致性方案。处理流程大致是前端提交秒杀请求应用层检测资格、扣减 Redis 库存、记录用户幂等标识发送 MQ 消息消息包含用户 ID、商品 ID、幂等 IDMQ 消费者异步写订单写入时判断幂等表是否存在该幂等 ID如果订单写入失败通过定时对账任务发现并回补库存。这里的核心是幂等。消息消费者在写订单前会先查询“幂等记录表”如果发现同一个幂等 ID 已经处理过就直接返回成功避免消息重复消费导致重复下单。事务边界划在“缓存扣减成功并发送 MQ 成功”这一节点。只要 MQ 消息可靠投递最终订单一定会创建成功。如果 MQ 发送失败需要立即回补 Redis 库存保证数据一致。6. 配置中心 Apollo 与 Nacos 的应用6.1 配置中心在秒杀场景的价值秒杀期间系统参数随时可能需要调整最典型的就是限流阈值、活动开关、商品上下架状态。如果每次调整都要修改配置文件并重新发布会浪费大量时间大促的分秒必争根本等不起。配置中心解决了这个问题。把限流速率、活动开关、降级阈值、商品库存配置等全部外置到配置中心运维调整配置后应用可以在秒级感知并生效。项目里有几个实际使用的场景动态调整商品维度的令牌桶速率紧急下架某个异常商品开启全局限流降级开关调整用户资格校验的白名单和黑名单。比如秒杀开始后发现某个商品的请求量远超预期导致该商品分片所在 Redis 节点负载过高此时可以立即下调该商品的令牌桶速率或者直接关掉该商品的活动开关避免风险扩散。6.2 Apollo 与 Nacos 对比与选择项目初期在 Apollo 和 Nacos 之间犹豫了一段时间两个都是业界使用非常广泛的开源中间件。我需要做一个比较准确的对比而不是简单地说“看团队熟悉度”。对比维度NacosApollo功能定位注册中心配置中心一体化专注于配置管理强项在配置治理配置推送时效支持实时推送整体表现不错长轮询秒级推送推送机制成熟稳定权限管理有基础权限但功能相对简单权限粒度细可精确到 Key 级别配置审计有但相对弱一些发布历史、回滚、审计都比较完善部署成本较低环境依赖较少依赖 MySQL 等多个组件部署略重适合场景微服务架构中使用 Nacos 做注册发现的团队大型团队配置多、权限要求高的场景最终这个项目根据已有微服务技术栈选择了 Nacos因为项目本身已经用 Nacos 做服务注册与发现如果额外引入 Apollo相当于多维护一套配置系统成本会增加。隔离成独立配置中心的做法也很多但没必要为了“多”而引入更多组件。6.3 动态开关与预案切换配置中心的应用代码并不复杂。以 Nacos 为例Spring Cloud 项目中可以用RefreshScope标注配置类当 Nacos 配置变更推送后应用会自动刷新Component RefreshScope public class SeckillConfig { Value(${seckill.limiter.rate:1000}) private int limiterRate; Value(${seckill.activity.enable:true}) private boolean activityEnable; public int getLimiterRate() { return limiterRate; } public boolean isActivityEnable() { return activityEnable; } }秒杀请求入口处读取这个配置类当 activityEnable 为 false 时直接返回活动已结束不再处理后续业务。预案切换是配置中心发挥作用的关键场景。项目里专门准备了几套预案配置正常、压测、限流收紧、全链路降级等。大促前通过配置中心一次性推送到所有节点随时可以切换。这一点很重要因为秒杀当天如果出现异常往往没有太多时间慢慢排查一套可预置的降级预案能省下大量救火时间。7. 常见问题与排查记录7.1 超卖与少卖问题复盘项目联调期间出现过一次超卖原因是扣减 Redis 库存后订单创建的异步流程并发执行同一个用户或者多个用户同时通过了库存校验创建订单时没有再次做数据库库存校验。类似这样的问题建议在数据库层面加最后一道防线的校验UPDATE seckill_stock SET stock stock - 1 WHERE goods_id ? AND stock 0只有受影响行数为 1才算扣减成功。数据库库存校验不能完全替代 Redis 扣减因为数据库的性能扛不住秒杀流量但它可以作为兜底防止缓存和数据库不一致时产生超卖。少卖问题的出现往往是消息丢失。MQ 消费者收到消息后如果创建订单失败又没有做库存回补就会出现数据不一致。排查心得是一定要建立定时对账任务定期比较 Redis 剩余库存和数据库售出数量的总和是否等于初始库存。差异数据通过告警系统通知值班工程师处理。7.2 缓存穿透、击穿与雪崩处理秒杀项目中 Redis 承担了绝大部分读请求一旦缓存失效数据库会瞬间被打垮。项目里针对三种常见风险做了处理缓存穿透发生在请求的 Key 在 Redis 和数据库中都不存在的情况。比如用户传了一个不存在的商品 ID每次都会穿透到数据库。解决方式是缓存空值并设置短过期时间同时加一层参数校验过略非法商品 ID。缓存击穿指某个热点 Key 过期瞬间大量请求同时访问数据库。项目里对热点商品的缓存不设置物理过期时间而是用逻辑过期时间加上异步刷新也就是后台任务定期更新缓存避免集中失效。缓存雪崩是大面积 Key 同时过期导致的。处理方式是在预热时给 Key 的过期时间加一个随机偏移量让过期时间分散开不至于在某一个时间点集体失效。7.3 血泪经验与建议大促前压测是真的能发现问题。开始我只压测了单机接口测出来 QPS 还不错结果压测集群时发现 Redis 大 Key 成了瓶颈最后只能紧急拆分并重新预热。所以建议压测时一定要从负载均衡入口整链路压测而不是只测单个服务节点。另外不要迷恋“百万 QPS”这个名词。百万 QPS 是整个网络入口的流量核心业务真正需要处理的请求可能只有几万甚至几千。设计目标应该放在“如何优雅地拒绝大多数请求”上把系统变成了一个精准的“过滤器”而不是一个无所不能的处理器。还有一个经验是监控要提前做好。Redis 的命中率、线程池队列积压数量、MQ 消费延迟、接口 TP99 耗时这些指标在大促期间必须一目了然。项目上线后我专门做了一套大屏监控把核心指标汇总展示高峰期能节省大量排查时间。秒杀系统的成败往往不取决于某一个亮点技术而在于所有环节是否滴水不漏。

秒杀系统高并发架构：Redis限流与库存扣减实战解析

相关推荐

第7讲：并查集

Django+Vue宠物商店实战：库存原子扣减、订单状态机与RBAC权限落地

零基础本地部署DeepSeek-R1：Ollama三步跑通与强化学习原理解析

更多资讯

多微电网拓扑设计的约束差分进化算法与Matlab实现

破解登记之后的运营难题：qData 数据中台专业版六大能力，接住企业数据资产五个问题

基于SpringBoot+Vue的教师工作量管理系统开发实战

AI面试八股文-16_16-简历相关

【鸿蒙心迹】HarmonyOS学习笔记04：ArkTS变量与类型

AI 选题成主流，计算机专业毕设热门选题：含大数据 / 小程序 / 深度学习 / RAG/Web 系统等方向，可以照着抄

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

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

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

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

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