我见过太多项目栽在Redis这层配置上。Spring Boot集成Redis本身五分钟就能跑通但到了生产环境压测一上来现象特别统一先是连接超时接着key前缀冒出一堆\xAC\xED\x00\x05t\x00的乱码再往后跨服务反序列化直接报ClassNotFoundException。运维说代码有问题开发说Redis有问题最后查了一圈才发现问题全出在连接工厂、序列化器、RedisTemplate这三件套没有按生产标准配。这篇文章不聊Redis命令怎么背也不讲分布式锁的九九八十一式就把这三件事讲透连接工厂怎么配才算稳、序列化器怎么选才不埋雷、RedisTemplate怎么封装才好用。适合刚接手Spring Boot项目的同学也适合已经被线上Redis坑过、想系统性补课的人。看完你至少能拿出一个直接对标生产环境的配置方案知道每个参数为什么这么调。1. 从“能连上”到“生产可用”差的就是这三件套1.1 先搞清楚三件套的职责分工很多人把Redis集成理解成“引入依赖配置host和port注入RedisTemplate就完事”。这没错但只覆盖了“能连上”这个层面。生产环境要解决的是另一个问题在大流量、多实例、跨语言协作的场景下连接怎么维持、数据怎么存取、类型怎么转换。这三件套各管一段连接工厂RedisConnectionFactory管的是底层网络连接。包括连哪个Redis地址、超时多久算失败、连接池多大、怎么应对Redis主从切换或者哨兵节点变化。它决定你的应用跟Redis之间的通道稳不稳。序列化器RedisSerializer管的是数据在内存和传输链路之间的形态转换。Java对象要落进Redis要么转成字节数组要么转成JSON字符串从Redis读出来又要从字节还原成Java对象。序列化器选错轻则key可读性差重则跨服务根本读不出来。RedisTemplate管的是开发体验和类型安全。它封装了底层连接操作给你提供opsForValue()、opsForHash()这类面向业务的API。但Template本身不聪明你不在初始化阶段把序列化器正确装配进去它就默默用JDK默认序列化给你埋雷。三者关系可以类比成快递链路连接工厂是运输车队序列化器是打包规范RedisTemplate是快递单填写界面。车跑得再快打包标准不一致包裹到了对端还是打不开。1.2 为什么默认配置不能直接上生产Spring Boot的自动配置在开发阶段非常好用因为它帮你兜底了所有设置。但默认值考虑的是“让你启动不报错”不是“让系统在压力下正常运行”。默认配置至少有三个隐患序列化器默认是JdkSerializationRedisSerializer数据以Java二进制序列化格式写入Redis。你在redis-cli里看到的key长这样\xAC\xED\x00\x05t\x00\x0Buser:1001。可读性等于零而且这类数据就算让另一个Java服务读类的全限定名对不上也一样反序列化失败。连接超时默认2秒在CPU飙高或者Redis慢查询拖累网络线程时这个值不够稳妥。生产环境我习惯设置为3秒到5秒给GC停顿留出余量。默认不开启连接池校验Lettuce这种基于Netty的客户端虽然能多路复用连接但空闲连接被服务端断开后如果客户端没有及时发现第一次请求会触发重连带来毛刺延迟比平时慢几百毫秒。不要以为只要“能跑”就等于“没问题”。生产事故往往发生在数据量上涨的那一刻而那时候再去追查配置成本远高于一开始就配好。2. 连接工厂生产环境的网络地基2.1 Lettuce还是Jedis2025年了别纠结很多人还停留在“Jedis是官方推荐Lettuce是Spring Boot默认”的认知。实际上Spring Boot从2.0开始默认集成Lettuce这是有明确理由的。Jedis是阻塞式IO模型实例不是线程安全的每一个线程要操作Redis必须从连接池里借一个独立连接用完归还。在高并发场景下池子就是瓶颈连接创建和销毁非常频繁。Lettuce底层是Netty基于非阻塞IO同一个连接可以被多个线程共享使用命令以异步方式复用连接通道。这意味着Lettuce对连接池的依赖远低于Jedis连接数不必开得很大。我在生产环境见过两种极端一种是Jedis池配置过大比如max-active开到200结果Redis连接数被打满服务端直接拒绝新建连接另一种是Lettuce不配池参数全靠默认单连接扛遇到慢命令直接拖垮全部请求。我的建议很简单跟着Spring Boot默认走用Lettuce但一定要打开连接池并显式配置连接校验。2.2 生产级连接池参数怎么定先看一份贴合生产环境的配置Spring Boot 3.x配置前缀是spring.data.redisspring: data: redis: host: 10.0.0.12 port: 6379 password: ${REDIS_PASSWORD} database: 0 timeout: 3s lettuce: pool: max-active: 16 max-idle: 8 min-idle: 2 max-wait: 3s shutdown-timeout: 200ms connect-timeout: 2s需要注意的是Spring Boot 2.x从2.4版本左右开始配置前缀是spring.redis到了3.x统一为spring.data.redis。如果你从旧项目升级这地方很容易踩空配置不生效但也不报错因为未知配置项默认会被忽略。重点解释这几个参数为什么这么设max-active: 16Lettuce的连接是共享的16个连接足够支撑每秒几千次操作。如果用了Jedis这个数通常需要按“峰值QPS × 平均耗时秒数”估算。比如峰值QPS是2000单次Redis操作平均1ms那理论需要2个连接再考虑波动留3到5倍余量取8到16比较合理。核心原则是连接数不是越多越好多到服务端放不下就是灾难。max-wait: 3s当连接池耗尽时获取连接的等待时间。默认 -1 表示无限等待这在生产环境非常危险请求会像雪球一样堆积。我习惯设置为3秒超时直接抛出异常让上层走降级而不是无限阻塞线程。min-idle: 2保持最少2个空闲连接避免业务低谷后流量突增时临时建连的延迟。注意Lettuce的min-idle是异步补充的不是启动时就立刻建好所以刚重启的瞬间仍然可能有短暂冷启动开销。timeout: 3s读写超时。设太短Redis慢查询时大量误判超时设太长下游故障时线程大量阻塞。3秒是我在多数业务系统里的折中值。shutdown-timeout: 200ms应用关闭时等待连接释放的时间。太短可能导致命令尚未执行完就强制断开数据还没写进去就退了。2.3 主从、哨兵、集群环境下连接工厂的选择如果你的环境是主从复制连接不需要特殊处理客户端连主节点读写从节点用于备份。但要注意一旦主节点宕机触发哨兵切换客户端需要感知新主节点地址。哨兵模式下配置spring.data.redis.sentinelspring: data: redis: sentinel: master: mymaster nodes: 10.0.0.11:26379,10.0.0.12:26379,10.0.0.13:26379这里只填哨兵节点地址客户端通过哨兵查询当前主节点。生产上建议至少3个哨兵节点避免哨兵自身脑裂。集群模式下配置spring.data.redis.cluster.nodesspring: data: redis: cluster: nodes: 10.0.0.21:6379,10.0.0.22:6379,10.0.0.23:6379,10.0.0.24:6379,10.0.0.25:6379,10.0.0.26:6379 max-redirects: 3max-redirects是当key不在当前节点时客户端跟随重定向的最大次数。集群模式不要手动去选db集群只有一个db0。还有个隐藏细节连接工厂在集群模式下会自动禁用某些特性比如事务MULTI/EXEC在集群中跨slot无法使用Lettuce碰到这种命令会直接报错。所以业务代码里不要假设“Redis支持事务”到了集群环境行为完全不一样。2.4 连接被服务端断开导致毛刺延迟Redis服务端默认有个timeout配置默认通常是0不断空闲连接但很多团队会主动设置成300秒或者更短来释放资源。这就带来一个问题Lettuce连接空闲超过300秒后服务端已经断开客户端不知道下次请求会先收到一个EOF然后触发重连。这个重连过程会带来几十到几百毫秒的额外延迟。解决方式是在连接池配置里开启连接校验。Lettuce支持在获取连接时执行一次PING验证spring: data: redis: lettuce: pool: enabled: true从根本上缓解这个问题还可以在服务端运维层面禁用空闲超时或者设置足够长的空闲时间让连接在业务低峰期也足够活跃。3. 序列化器让数据在Java和Redis之间说同一种话3.1 默认序列化为什么是“万恶之源”RedisTemplate如果不做任何设置valueSerializer默认是JdkSerializationRedisSerializer它把Java对象通过Java内置序列化机制转成二进制字节流。这带来三个实际问题可读性极差redis-cli里看到的是\xAC\xED\x00\x05t\x00\x0Buser:1001没法直接通过Redis客户端排查数据。跨语言完全不可用Python、Go、Node.js服务想读取这份数据必须实现Java序列化协议基本等于不可能。数据膨胀严重JDK序列化会写入类描述、继承关系等大量元信息一个几KB的Java对象序列化后可能膨胀到几十KB。更坑的是只要反序列化时类结构发生变化比如新增字段、修改包名直接抛出SerializationException。线上发布后再回滚代码缓存里的旧数据全读不出来。所以生产级应用第一原则默认序列化器只用于开发调试上生产前必须换掉。3.2 四类主流序列化器的选型对比序列化器存储格式可读性跨语言典型适用场景JdkSerializationRedisSerializerJava二进制差不支持不推荐生产使用StringRedisSerializer原始字符串好支持key以及String类型的valueJackson2JsonRedisSerializerJSON好支持已知类型的对象配合ObjectMapper控制类型信息GenericJackson2JsonRedisSerializerJSON class类型标记好受限泛型场景反序列化时不丢失类型StringRedisSerializer最轻量它对key和value都要求是String写入时直接UTF-8编码读出直接还原。很多团队把key统一用这个保证可读性。Jackson2JsonRedisSerializer需要构造时传一个对象类型例如new Jackson2JsonRedisSerializer(User.class)。它只处理JSON结构不含类型信息反序列化时按构造时的类型来。好处是数据干净坏处是如果缓存多类型对象需要针对每种类型建不同的Template用起来麻烦。GenericJackson2JsonRedisSerializer天然适配多类型场景它在JSON中写入一个class字段记录全限定类名。反序列化时读到这个字段自动加载对应类。对于复杂的泛型结构比如ListUser它能正确还原成指定类型不用手动指定。但要注意GenericJackson2JsonRedisSerializer有一个安全隐患class字段可以被攻击者篡改强制JVM加载任意类。Spring官方文档明确警告不要用这个序列化器处理不可信数据源。生产上如果你只缓存自己服务写入的数据风险可控如果接收外部输入并直接存入Redis要额外做类白名单校验。3.3 生产环境我推荐的组合方案我的生产级组合非常简单被多个项目验证过key和hash的field一律StringRedisSerializer普通valueGenericJackson2JsonRedisSerializer需要严格控制类型的场景单独定义一个ObjectMapper用Jackson2JsonRedisSerializer绝不使用默认的JdkSerializationRedisSerializer如果项目对性能要求极高并且所有服务都是Java可以考虑Kryo或者Protostuff。这类二进制序列化器体积小、速度快但会牺牲可读性并且需要额外的兼容维护工作。大多数业务系统用JSON就足够了别为一点性能引入不必要的复杂度。3.4 序列化器必须成对配置key、value、hash一个都不能漏RedisTemplate里有四类序列化器keySerializer、valueSerializer、hashKeySerializer、hashValueSerializer。很多人配了前面两个就以为完事了等用到opsForHash()时又出现乱码。这是因为hash结构在Redis里是field-value映射field和value是独立的序列化通道。你只配了keySerializerhash的field就会被当成value来序列化最终field变成乱码。所以初始化RedisTemplate时必须四类全配齐template.setKeySerializer(stringRedisSerializer); template.setValueSerializer(jsonRedisSerializer); template.setHashKeySerializer(stringRedisSerializer); template.setHashValueSerializer(jsonRedisSerializer);这个细节平时不显眼一旦线上用opsForHash()缓存数据排查起来非常痛苦因为你看到的field是一串\xAC\xED\x00\x05t\x00...根本不知道对应业务的哪个字段。4. RedisTemplate日常开发的主力工具4.1 一份可直接抄的RedisConfig说了这么多上代码。这是一份能直接对标生产环境的配置类Configuration public class RedisConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory connectionFactory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(connectionFactory); StringRedisSerializer stringSerializer new StringRedisSerializer(); GenericJackson2JsonRedisSerializer jsonSerializer new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(stringSerializer); template.setValueSerializer(jsonSerializer); template.setHashKeySerializer(stringSerializer); template.setHashValueSerializer(jsonSerializer); template.afterPropertiesSet(); return template; } }这段代码有两个关键点afterPropertiesSet()必须在返回前调用。它负责检查序列化器是否为空如果没有调用RedisTemplate内部的一些初始化逻辑可能不完整导致序列化器不生效。泛型声明为String, Objectkey固定String保证可控性value用Object给业务留灵活度。如果想用StringRedisTemplate直接操作简单键值可以直接注入框架自带的StringRedisTemplate它的序列化器固定是StringRedisSerializer不需要额外配置。4.2 给RedisTemplate加一层“业务适配”封装直接在Service里塞redisTemplate.opsForValue()和redisTemplate.opsForHash()没有错但代码会显得很散。我更推荐在缓存组件层做一个薄封装把缓存操作收敛到一起Component public class RedisCacheService { private final RedisTemplateString, Object redisTemplate; public RedisCacheService(RedisTemplateString, Object redisTemplate) { this.redisTemplate redisTemplate; } public void set(String key, Object value, long timeout, TimeUnit unit) { redisTemplate.opsForValue().set(key, value, timeout, unit); } public T T get(String key, ClassT clazz) { Object val redisTemplate.opsForValue().get(key); if (val null) { return null; } if (clazz.isInstance(val)) { return clazz.cast(val); } throw new ClassCastException(缓存值类型不匹配: val.getClass()); } public boolean tryLock(String lockKey, String requestId, long expireSeconds) { return Boolean.TRUE.equals( redisTemplate.opsForValue().setIfAbsent(lockKey, requestId, Duration.ofSeconds(expireSeconds)) ); } public void unlock(String lockKey, String requestId) { String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; DefaultRedisScriptLong redisScript new DefaultRedisScript(script, Long.class); redisTemplate.execute(redisScript, Collections.singletonList(lockKey), requestId); } }这个封装解决三个实际问题把opsForValue().set(key, value, timeout, TimeUnit)这种长链调用收敛成业务语义明确的set方法。在get时做类型检查避免类型不匹配的隐蔽错误拖到业务层才暴露。分布式锁用Lua脚本释放保证判断和删除是原子操作避免误删别人的锁。注意tryLock用到了setIfAbsent加过期时间这是Redis实现分布式锁的标准姿势。释放锁必须比对值之后再删直接delete(key)会误删其他线程刚获取的锁。4.3 缓存注解的序列化配置如果项目使用Cacheable、CachePut注解RedisCacheManager也会有自己的序列化器配置默认同样使用JdkSerialization导致缓存数据变成一堆看不明白的二进制。自定义CacheManagerBean public RedisCacheManager cacheManager(RedisConnectionFactory connectionFactory) { RedisCacheConfiguration config RedisCacheConfiguration.defaultCacheConfig() .entryTtl(Duration.ofMinutes(30)) .serializeKeysWith(SerializationPair.fromSerializer(new StringRedisSerializer())) .serializeValuesWith(SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer())) .disableCachingNullValues(); return RedisCacheManager.builder(connectionFactory) .cacheDefaults(config) .build(); }这里注意disableCachingNullValues()。默认情况下被Cacheable注解的方法返回null时也会生成一条缓存记录。如果你在缓存读到的null和真实值的null之间没有区分容易出现缓存穿透。禁用后null不会被缓存配合一层布隆过滤器可以更安全。不同业务的TTL需求不同可以在注解上用Cacheable(cacheNames user:info, key #userId)同时为不同cacheNames配置单独的过期策略。更灵活的做法是单独再注册一个短TTL的CacheManager用于验证码、会话类数据。4.4 Spring Boot 3.x下RedisTemplate与泛型的兼容性Spring Boot 3.x采用Jakarta命名空间Redis序列化在使用GenericJackson2JsonRedisSerializer时如果对象包含Java 8日期类型反序列化时可能报InvalidDefinitionException。原因是默认ObjectMapper没有注册JavaTimeModule。解决办法是自定义ObjectMapper并手动构造序列化器ObjectMapper objectMapper new ObjectMapper(); objectMapper.registerModule(new JavaTimeModule()); objectMapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS); objectMapper.activateDefaultTyping(LaissezFaireSubTypeValidator.instance, ObjectMapper.DefaultTyping.NON_FINAL, JsonTypeInfo.As.PROPERTY); GenericJackson2JsonRedisSerializer jsonSerializer new GenericJackson2JsonRedisSerializer(objectMapper);activateDefaultTyping这一行是GenericJackson2JsonRedisSerializer内部实现类型信息的关键。如果你想深度定制序列化行为一定要保留这段配置否则反序列化时类型信息会丢失。5. 常见问题与排查技巧实录5.1 key变成“\xAC\xED”乱码十有八九是序列化器没配对现象redis-cli里keys * 能看到一堆以\xAC\xED开头的key应用代码里能读到值但Redis客户端和跨服务根本没法操作。原因RedisTemplate的keySerializer没有被设置成StringRedisSerializer默认用了JdkSerialization。排查顺序先看代码里有没有自定义RedisConfig如果没有说明自动配置把默认序列化器装上了。如果有但没生效检查afterPropertiesSet()是否被调用。修复按4.1节的配置类把keySerializer和hashKeySerializer设置成StringRedisSerializer。这里还有个隐蔽情况项目里同时存在StringRedisTemplate和自定义RedisTemplate业务代码一部分用StringRedisTemplate写key一部分用自定义RedisTemplate读。两者key序列化方式不同读别人的数据就会出现null。解决思路是维护一套统一的缓存工具类禁止业务代码直接注入RedisTemplate。5.2 数据写入成功但跨服务反序列化失败现象服务A写入缓存没有问题服务B读取时报ClassNotFoundException或者ClassCastException。原因服务A用了带JVM类型信息的序列化器或者GenericJackson2JsonRedisSerializer中的class类名指向服务A的类服务B没有这个类。排查方法先redis-cli查看key的结构。redis-cli --scan --pattern user:* | head -10 redis-cli get user:1001如果value里能看到class字段说明是GenericJackson2JsonRedisSerializer写入的。检查类全限定名是否两边一致。修复跨服务共享的缓存对象建议放到公共模块里保证类路径一致。如果无法共享优先用String JSON字符串传输业务侧自行反序列化。5.3 压测时报RedisCommandTimeoutException现象压测开始后几分钟日志频繁打印Redis命令超时错误信息类似io.lettuce.core.RedisCommandTimeoutException: Command timed out after 3 second(s)排查步骤先看Redis服务端监控确认是不是服务端CPU、内存、慢查询问题。再看连接池监控确认max-active是否打满如果max-wait设置为-1请求会无限排队表现为接口RT持续上涨。检查是否有大key例如一个list里有几十万条数据每次操作LRANGE全量取出会导致Redis工作线程长期阻塞。常见原因排优先级慢查询 大key 连接池耗尽 网络抖动。建议先用redis-cli --latency观察网络延迟基线再用SLOWLOG GET 10查看慢命令。5.4 RedisTemplate执行Lua脚本时报错现象使用redisTemplate.execute(script, keys, args)报ERR Error compiling script或者NOPROTECT。原因Lua脚本语法问题比较少见更常见的是脚本里用了集群不支持的跨slot操作或者redis.call(get, KEYS[1])的KEYS数组为空。修复确保所有操作同一个key的脚本KEYS参数至少包含一个key。集群模式下脚本涉及的所有key必须属于同一个slot通常做法是给key加统一的hash tag比如{lock}:order:1001强制hash到同一个slot。5.5 序列化器导致的内存膨胀现象Redis内存增长异常迅速查看大key发现单个value几十KB甚至上百KB但业务数据本身只有几KB。原因GenericJackson2JsonRedisSerializer写入的JSON除了字段值还有class类型标记。如果对象嵌套层级很深每个嵌套对象都带类型信息膨胀更加明显。优化方案有三种改用Jackson2JsonRedisSerializer不写类型信息按已知类型反序列化。对高频访问的大对象手动在业务层压缩比如Gzip后再存入Redis。使用Kryo等二进制序列化体积最小但要维护类型注册表。实际业务里成本最低的优化是从“什么都存”改成“只存必要字段”。很多缓存对象里有大量日志字段、审计字段缓存利用率极低精简后内存能省三分之一。6. 必须避开的几类反模式6.1 把Redis当数据库用但没有恢复机制Redis的持久化机制AOF和RDB是用来恢复内存数据的但无论哪种都做不到数据库级别的持久保证。生产上我见过团队把订单记录直接写Redis服务重启后数据丢了一部分原因就是没开启AOF或者AOF策略是everysec正好丢了那一秒的数据。Redis定位是缓存、限流、分布式锁、消息队列这些场景不是替代MySQL。核心业务数据该落库还是落库Redis只承担加速层。6.2 不分环境共用一套Redis开发、测试、生产共用Redis实例是灾难。开发环境清缓存会把生产的预热数据全删掉更麻烦的是key设计冲突生产数据被开发环境的数据覆盖。强烈建议至少做三套Redis环境key设计上带环境前缀例如prod:user:info:1001、dev:user:info:1001。这样即便配置失误连错环境也不会静默污染另一个环境的数据。6.3 操作大key不拆分大key是Redis生产事故的头号元凶。一个千万级别的hash、几十万元素的list任何对该key的操作都会阻塞Redis工作线程几秒钟期间所有请求全部排队等待。经验规则是String类型value超过10KB要警惕Hash类型field数量超过5000要拆分List类型元素超过1万要么分片要么换方案。即使不拆分至少要对大key做监控及时掌握它的增长速度。6.4 明明只需要String却让对象走了一遍JSON有相当多缓存场景本质上只有String类型的短数据比如验证码、限流计数。那么就不要用RedisTemplateString, Object加JSON序列化。直接用StringRedisTemplate以最原始的字符串形式读写不光快而且Mutou可读。最高效的团队规范通常是纯字符串数据一律StringRedisTemplate对象数据走自定义RedisTemplate缓存注解走自定义RedisCacheManager。三种工具职责分离谁也不越界。7. 写在最后的零零碎碎7.1 一次真实的连接池调优记录之前有个项目压测时发现Redis命令平均耗时1.2ms但到了QPS 3000时出现超时。排查确认服务端无慢查询、网络正常就是连接池设置有问题。初始配置max-active只有8按Lettuce多路复用应该够用但在长连接隔离场景下某些业务会占用连接导致池子交替耗尽。我把max-active调到32同时打开连接校验超时时间从2秒调整为3秒再压测就稳定了。这套参数不是从网上抄的是根据压测数据一步步调出来的。7.2 上线前必做的Redis检查清单根据我的经验每次发版前花十分钟过一遍这份清单能避免一大半生产事故[ ] RedisTemplate的四个序列化器均已显式配置不依赖默认值[ ] 连接池已启用max-wait不是-1timeout设置合理[ ] key统一带业务前缀例如order:info:1001[ ] 缓存对象有明确的TTL不会无限增长[ ] 大对象经过精简避免存储多余字段[ ] 哨兵/集群模式下Lua脚本的key使用相同的hash tag[ ] Redis实例开了AOF持久化并有定期备份[ ] 自定义ObjectMapper已注册JavaTimeModule支持LocalDateTime7.3 再送一个排查利器排查生产Redis问题我经常用这个组合命令快速定位异常key# 找出所有没设置TTL的key通常byte[]类型需要重点排查 redis-cli -a password --scan --pattern * | while read key; do ttl$(redis-cli -a password -n 0 ttl $key) if [ $ttl -1 ]; then echo No TTL: $key fi done批量查看key的内存占用redis-cli -a password --scan --pattern user:* | head -20 | while read key; do echo $key: $(redis-cli -a password memory usage $key) bytes doneMEMORY USAGE命令是Redis 4.0以后提供的非常直观地告诉你每个key占了多大内存。配合redis-cli --bigkeys可以整体扫描大key分布上线前跑一次比事后排查省心得多。我把上面这些配置和检核项沉淀成了一套项目模板每接手一个新项目就套用一次踩坑率明显下降。Redis本身不难难的是每个细节都到位连接工厂、序列化器、Template这三关过了生产环境就稳了一大半。如果你照这个方案落地后还是遇到奇奇怪怪的问题欢迎按文章里的排查思路逐项核对大部分都能在十分钟内定位到根因。