★ FEATURED ARTICLE 1. 事务失效的七宗罪我踩过的坑你大概率也会踩先讲个真实事故。几年前我维护过一个电商订单系统线上出了一个诡异的bug用户支付成功后订单状态正常更新但库存却莫名其妙多扣了一次。代码看起来完全没问题——service方法上明明白白标着Transactional数据库也确认是InnoDB。查了两天才定位到根因同一个类里方法A调用方法BB的事务注解根本没生效。这就是Spring事务最经典的坑之一自调用绕过代理。Transactional依赖AOP代理生效而Spring的代理机制决定了一个类内部的方法调用是不会经过代理对象的。this.orderService.update()拿到的这个this根本不是Spring容器里那个被代理过的bean而是原始对象。原始对象上的注解Spring根本看不见。结果就是你以为开启了事务实际上没有。库存扣减在无事务状态下执行订单那边一旦报错回滚库存早就提交了。1.1 自调用问题最隐蔽的事务杀手自调用这个坑的隐蔽之处在于它不会报错不会警告日志里什么都看不出来只有数据对不上账的时候才会暴露。Service public class OrderService { Transactional public void createOrder(OrderDTO dto) { // 扣库存 stockService.deduct(dto.getSkuId(), dto.getQuantity()); // 插入订单 orderMapper.insert(buildOrder(dto)); // 这里调用了自身方法事务注解失效 this.sendNotification(dto); } Transactional(propagation Propagation.REQUIRES_NEW) public void sendNotification(OrderDTO dto) { // 通知逻辑 } }上面这段代码里sendNotification的REQUIRES_NEW完全无效。因为this.sendNotification()走的是原始对象不是代理。解决办法有三个把需要事务的方法挪到另一个Service类——最推荐职责也最清晰。注入自身代理Autowired private OrderService self;然后调用self.sendNotification()。使用AopContext.currentProxy()需要开启EnableAspectJAutoProxy(exposeProxy true)然后((OrderService) AopContext.currentProxy()).sendNotification()。方案2最实用但要注意循环依赖问题——Spring 4.3之后字段注入的循环依赖是允许的但构造器注入就不行。方案3代码看着别扭但确实有效。1.2 非public方法注解白写了Transactional用在private或者protected方法上Spring容器启动时根本不报错但方法执行时事务就是没开。原理不复杂Spring AOP生成代理的时候JDK动态代理基于接口只代理public方法CGLIB虽然能代理非public方法但Spring官方明确说了Transactional只支持public方法。最骚的是如果你把Transactional放在public方法上、但里面调用了private方法private方法里的事务注解同样无效——因为事务边界已经在public方法的代理上确定了内层调用不会再开启新事务除非传播行为是REQUIRES_NEW。我见过不少项目把Transactional加到private方法上然后一脸疑惑地说为什么回滚了没生效。排查方法很简单看日志里有没有TransactionInterceptor的getTransaction记录没有就是代理没走。1.3 异常被吞回滚了个寂寞这是最常见也最无语的一种。Java的检查型异常checked exception默认不会触发Spring事务回滚但很多人不知道这一点随手写了个throws Exception然后事务就失效了。Transactional public void transfer(Account from, Account to, BigDecimal amount) throws Exception { accountMapper.decrease(from.getId(), amount); accountMapper.increase(to.getId(), amount); // 业务校验不通过抛了个业务异常 throw new BizException(余额不足); }BizException如果是继承Exception而不是RuntimeException上面这个事务不会回滚钱就凭空消失了。Spring的默认回滚策略是只回滚RuntimeException和Error。检查型异常如IOException不会触发回滚因为Spring认为你既然显式声明了这个异常说明你可以处理它事务继续提交是合理的。解决方案两个方向业务异常统一继承RuntimeException——大多数项目的做法最简单。在Transactional上显式指定Transactional(rollbackFor Exception.class)——最稳一劳永逸。我个人的习惯是两者都做自定义业务异常继承RuntimeException同时在Transactional上写rollbackFor Exception.class。虽然看起来冗余但团队里总有人会写检查型异常。1.4 多线程子线程异常主线程事务照样提交Transactional的事务上下文存在ThreadLocal里子线程拿不到父线程的事务上下文。Transactional public void batchProcess(ListOrder orders) { orders.parallelStream().forEach(order - { // 这里抛异常父线程事务不会感知 processOne(order); }); }如果一定要在多线程里用事务只能每个线程自己开事务用TransactionTemplate包住子线程的任务代码然后在线程池层面做异常聚合——子线程里有任何失败主线程如何决定是否整体回滚需要自己实现协调逻辑。这个问题在批量导入、报表生成、定时任务场景里非常常见。我的建议是批量任务尽量不用Transactional包整段而是每条或每批用TransactionTemplate单独开事务配合失败记录表做补偿。这样既能保证数据一致又不会因为一个线程失败导致大批量回滚。1.5 数据库引擎不支持事务这个坑现在少了但老项目中还能见到。MySQL的MyISAM引擎根本不支持事务你注解标得再多也没用。确认方法很简单SHOW TABLE STATUS WHERE Name your_table;看Engine字段InnoDB支持事务MyISAM不支持。另外如果表是MyISAMSpring事务管理器初始化时也不报错执行时DataSourceTransactionManager还是会调setAutoCommit(false)但引擎层面不认等于白忙。1.6 final类或final方法CGLIB也救不了Spring事务默认用AOP代理。如果目标类配置了JDK动态代理基于接口那没问题如果走CGLIB基于类继承生成子类那么final类无法被继承final方法无法被重写代理自然失效。Spring Boot 2.x之后默认proxyTargetClasstrue走CGLIBfinal问题就浮出水面了。很多人把service类写成final为了防继承结果事务全失效。排查方法启动时看日志里是JdkDynamicAopProxy还是CglibAopProxy再看你的类和方法有没有final修饰符。1.7 事务管理器没配置或配置错了Spring Boot的DataSourceAutoConfiguration会自动配置DataSourceTransactionManager但你如果引入了多数据源或者自定义了DataSource而没有配套注册PlatformTransactionManager那Transactional就会失效。另外EnableTransactionManagement注解在Spring Boot里默认开启不需要你重复添加。但如果你用了Spring MVC非Boot项目忘了加EnableTransactionManagement事务也会静默失效。排查清单很简单Transactional方法执行的线程栈里有没有TransactionInterceptor有就是代理生效了没有就是代理没生效。2. Spring事务的底层运作机制从JDBC到动态代理很多人用Transactional用了好几年但完全不知道它背后发生了什么。面试被问Spring事务是怎么实现的只会答AOP两个字就再也说不出更多了。其实底层链路没那么玄拆开看就三层JDBC的事务能力、Spring的事务抽象、AOP的代理包装。2.1 第一层JDBC的事务基石万事万物都离不开JDBC。Spring事务再花哨落到底层就是这三行代码Connection conn dataSource.getConnection(); conn.setAutoCommit(false); // 关闭自动提交 conn.commit(); // 提交 conn.rollback(); // 回滚setAutoCommit(false)的意思是之后的SQL不会立即生效必须等commit()才真正写入数据库MySQL的binlog和redolog层面是另一套机制。如果中途异常调用rollback()之前的所有操作全部撤销。所以Spring事务的本质就是帮你管理Connection在合适的时机调用commit或rollback。就这么简单。2.2 第二层PlatformTransactionManager抽象Spring抽象了一个接口——PlatformTransactionManager核心方法就三个public interface PlatformTransactionManager { TransactionStatus getTransaction(TransactionDefinition definition); void commit(TransactionStatus status); void rollback(TransactionStatus status); }getTransaction获取或创建事务。注意这里的措辞——如果你已经在事务里根据传播行为决定是复用当前事务还是挂起后新建。commit提交事务。但提交前会检查TransactionStatus里的rollbackOnly标记如果之前有人标记了只回滚这里会抛UnexpectedRollbackException。rollback回滚事务。常用的实现是DataSourceTransactionManager针对Hibernate有HibernateTransactionManager针对JPA有JpaTransactionManager。DataSourceTransactionManager的doBegin方法做了几件事从DataSource拿一个Connection。如果当前Connection是自动提交模式关闭它并记下来方便事务结束恢复。设置隔离级别如果TransactionDefinition指定了。设置只读标志readOnlytrue会走Connection.setReadOnly对MySQL的InnoDB来说这能优化一些查询路径。把这个Connection绑定到TransactionSynchronizationManager的ThreadLocal里。后面的DAO操作拿到的Connection就是从TransactionSynchronizationManager里取的。这就是同一个事务里所有SQL共用同一个数据库连接的原理——ThreadLocal绑定。2.3 第三层AOP代理的切入点Spring事务的AOP基于TransactionInterceptor它实现了MethodInterceptor拦截所有被Transactional标记的方法。调用链是这样的外部调用orderService.createOrder()实际调用的是代理对象的方法。TransactionInterceptor.invoke()被触发先调用TransactionAspectSupport的createTransactionIfNecessary。根据Transactional上的配置传播行为、隔离级别、超时等调用PlatformTransactionManager.getTransaction()。执行业务方法。方法正常返回提交事务方法抛异常根据rollbackFor配置决定是否回滚。清理ThreadLocal中的连接恢复自动提交状态。所以Transactional加在哪个方法上代理就拦哪个方法——事务边界就是方法边界。方法跑多久事务就开多久。2.4 只读事务与UnexpectedRollbackException的真相热词里有一条UnexpectedRollbackException: transaction rolled back because it has been marked as rollback-only这是个非常经典的问题。场景是这样的方法A开启事务调用方法BB标记了rollback-onlytrue比如B捕获了异常但内部回滚逻辑已运行。然后A继续执行正常返回时调用commit()此时Spring发现事务被标记为rollback-only直接抛UnexpectedRollbackException事务回滚。换句话说你代码里没抛异常但事务已经注定要回滚了。这经常出现在try-catch吃了异常但没重新抛出的情况下。排查时看日志里有没有Transaction rolled back because it has been marked as rollback-only的WARN告警跟着调用栈就能找到是哪个方法把事务标记了。3. 事务传播行为与隔离级别什么时候用哪个别背口诀网上关于传播行为的口诀一大堆什么REQUIRED默认用REQUIRES_NEW记日志NESTED做嵌套背下来容易用对难。我把这几个传播行为逐个讲透配上真实场景你就能理解了。3.1 传播行为详解Spring定义了7种传播行为大部分项目用到的不超过4种但理解每一种的原理仍然重要。传播行为含义典型场景REQUIRED有事务就复用没有就新建默认值99%的场景用它SUPPORTS有事务就加入没有就无事务执行查询方法可选MANDATORY必须在事务中执行否则抛异常强制事务的方法REQUIRES_NEW挂起当前事务永远新建一个写日志、异步通知NOT_SUPPORTED挂起当前事务以无事务方式执行导出大数据量文件NEVER如果有事务就抛异常强制无事务的执行NESTED嵌套事务基于保存点Savepoint大批量循环处理单条失败不影响整体REQUIRED是默认值理解起来很简单Spring检查当前ThreadLocal里有没有绑定事务有就加入没有就新建一个。注意加入意味着共用一个事务、一个Connection、一套commit/rollback。内层方法抛异常回滚外层也一起回滚。REQUIRES_NEW的核心是挂起。逻辑是从TransactionSynchronizationManager里把当前事务的Connection解绑、挂起然后新建一个完全独立的事务持有独立的Connection。内层事务提交/回滚不影响外层事务。外层事务回滚内层已经提交的数据不会跟着回滚。典型场景就是操作日志业务方法开启事务日志记录要独立提交——不管业务成功还是失败日志都要写进去。如果你用REQUIRED业务回滚时日志也跟着回滚那排查问题的时候就看不到错误日志了。NESTED跟REQUIRES_NEW的区别要讲清楚。REQUIRES_NEW是物理事务独立的Connection、独立的commit/rollbackNESTED是逻辑事务基于Savepoint保存点。内层方法失败回滚到保存点外层可以继续执行外层最终提交时一起提交所有保存点之前的操作。但注意NESTED需要底层数据库支持保存点。MySQL的InnoDB支持但有些数据库不支持且JpaTransactionManager对NESTED的支持有限。实际项目中能用REQUIRES_NEW解决的就别用NESTED少踩坑。3.2 隔离级别脏读、不可重复读、幻读Spring事务隔离级别有五种对应JDBC的隔离级别隔离级别脏读不可重复读幻读说明DEFAULT---使用数据库默认MySQL默认REPEATABLE_READREAD_UNCOMMITTED会会会读未提交不推荐READ_COMMITTED不会会会Oracle默认REPEATABLE_READ不会不会会MySQL InnoDB下不会MySQL默认SERIALIZABLE不会不会不会串行化性能最差脏读读到别的事务未提交的数据。不可重复读同一事务内两次读取同一数据结果不一样因为别的事务提交了更新。幻读同一事务内两次查询返回的记录数不一样因为别的事务插入了新记录。MySQL的InnoDB在REPEATABLE_READ级别下通过MVCC多版本并发控制 Gap Lock间隙锁实际上消除了幻读问题。所以MySQL默认的REPEATABLE_READ比Oracle的READ_COMMITTED在某些场景下更严格。实际项目中我见过很多团队把隔离级别统一设成READ_COMMITTED理由是MySQL的RR有间隙锁并发插入容易死锁。这个说法有一定道理但不是绝对的。如果你的系统没有复杂的范围查询并发插入场景RR不会成为瓶颈如果你确实遇到死锁频繁再降级也不迟。3.3 事务超时与回滚策略Transactional(timeout 5)表示事务最多执行5秒超时则强制回滚。底层实现是JDBC的Connection.setNetworkTimeout或者由Spring在每次SQL执行前检查时间不同实现有差异。但要注意timeout是从事务开始到最后一次SQL执行的时间不是方法总耗时。如果你的方法在事务前做了一堆耗时操作比如远程调用这部分不计入事务超时。所以不要指望timeout能保护整体方法执行时间。关于回滚策略我再强调一次// 推荐写法 Transactional(rollbackFor Exception.class) // 或者只回滚特定异常 Transactional(rollbackFor BizException.class, noRollbackFor IllegalStateException.class)noRollbackFor用的场景不多但有一种情况很实用某些非关键数据比如统计缓存的更新失败不应该让主事务回滚可以列在noRollbackFor里。4. 编程式事务当Transactional真的不合适时Transactional是声明式事务用起来方便但有三个致命弱点事务粒度太大整个方法一个事务如果方法里有网络调用或批量循环事务会长时间占用数据库连接。自调用失效前面已经讲过了。无法精确控制提交时机想先做几步提交再继续做Transactional实现不了。这时候就该上手编程式事务了。Spring提供了TransactionTemplate。4.1 TransactionTemplate的用法Service public class OrderService { private final TransactionTemplate transactionTemplate; public OrderService(PlatformTransactionManager transactionManager) { this.transactionTemplate new TransactionTemplate(transactionManager); // 可以设置默认配置 this.transactionTemplate.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); this.transactionTemplate.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED); } public void createOrder(OrderDTO dto) { transactionTemplate.executeWithoutResult(status - { stockMapper.deduct(dto.getSkuId(), dto.getQuantity()); orderMapper.insert(buildOrder(dto)); }); } }TransactionTemplate.execute回调里你可以在任何地方开启事务块粒度完全由自己控制。更重要的是它彻底绕开了自调用问题——因为你是直接调用事务管理器不走代理。还有一个场景强烈推荐用TransactionTemplate大批量循环插入。如果用Transactional包住整个for循环几万条数据一个事务提交时数据库压力巨大一旦失败全部回滚代价太高。改成循环内用TransactionTemplate每100条一个事务失败了只回滚这一批配合日志记录失败批次整体效率和可靠性都高很多。4.2 手动控制TransactionStatus如果execute回调不适合你比如需要事务中间做分支判断、需要中途提交可以用更底层的PlatformTransactionManagerAutowired private PlatformTransactionManager transactionManager; public void complexBiz() { DefaultTransactionDefinition def new DefaultTransactionDefinition(); def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); TransactionStatus status transactionManager.getTransaction(def); try { // 业务逻辑1 dao.update(...); // 到这里先提交一次 transactionManager.commit(status); // 开启新事务 TransactionStatus status2 transactionManager.getTransaction(def); try { // 业务逻辑2 dao.insert(...); transactionManager.commit(status2); } catch (Exception e) { transactionManager.rollback(status2); throw e; } } catch (Exception e) { transactionManager.rollback(status); throw e; } }这段代码展示了如何手动控制多段事务但我强烈不建议在业务代码里写这种底层代码——容易出错而且代码很难读。99%的场景TransactionTemplate够用了。4.3 编程式事务的注意点TransactionTemplate是线程安全的可以做成Bean注入不要每次new一个。executeWithoutResult和execute的区别后者可以返回业务结果前者只能执行不能返回。需要返回值就用execute。事务回调里抛出的异常RuntimeException会触发回滚检查型异常默认不会。要回滚检查型异常需要手动status.setRollbackOnly()或者包装成RuntimeException。5. 多数据源与分布式事务跳出单库思维的边界单库单事务的好日子总有到头的时候。微服务一拆、分库一搞Transactional就管不住跨库的数据一致性了。我先讲清楚Spring事务在多数据源下的表现再展开分布式事务。5.1 多数据源下的事务各管各的如果你配置了两个DataSource比如一个主库一个从库Spring里注册了对应的两个PlatformTransactionManager同一个Transactional方法里操作了两个库——那这两个库的事务是互相独立的。主库提交成功、从库提交失败你没有任何办法通过单机事务解决。Spring Boot里处理多数据源的常规姿势是Transactional(transactionManager xxxTransactionManager)指定用哪个事务管理器。方法里操作另一个库那份数据不在事务保护范围内。所以多数据源场景下的策略是一个事务只操作一种数据源。跨数据源的业务要么拆分方法要么引入分布式事务方案不要指望Transactional救你。5.2 分布式事务的主流方案对比分布式事务是个大话题我只挑主流方案讲给个选型思路。XA协议两阶段提交2PCXA是最正统的分布式事务协议分两步准备阶段所有参与者执行SQL但不提交各自保留Undo/Redo log和提交阶段协调者发提交指令各参与者提交。问题在于准备阶段会一直持有数据库锁高并发场景下锁冲突严重性能非常差。Java里典型的实现是Atomikos、Bitronix。说实话互联网高并发场景用XA的很少了更多出现在金融等强一致性要求的内部系统。TCCTry-Confirm-CancelTCC把每个操作拆成三个阶段Try预留资源、Confirm确认执行、Cancel取消释放。优点是业务层面控制粒度性能比XA好很多缺点是侵入性极强每个业务都要写三套逻辑。典型场景账户转账。Try阶段冻结转出金额Confirm阶段扣款Cancel阶段解冻。这个方案需要深入理解业务才能写得对如果你只是想快速实现一个分布式事务TCC的学习成本挺高的。消息事务 最终一致性这是目前最常用、成本最低的方案。思路很简单利用本地事务把业务操作和发消息绑定在同一次数据库事务里通过消息中间件RocketMQ/RabbitMQ最终把数据变更同步给其他服务。举个订单和积分的例子开启本地事务插入订单表同时插入积分消息表。本地事务提交后后台任务或MQ的事务消息机制把积分消息表里未发送的记录发到MQ。积分服务从MQ消费消息给用户加积分。如果积分服务失败消息进入重试队列直到成功。这种方案做不到强一致中间会有一段数据不一致的时间窗口但绝大多数业务都能接受。核心机制是本地消息表实现成本低、不用引入重量级中间件是目前国内互联网公司的首选方案。Seata的AT模式Seata是阿里开源的分布式事务框架AT模式的思路是代理你的SQL记录Before Image和After Image数据快照在全局提交时自动执行补偿SQL。对业务代码侵入性很小但性能有一定损耗每行数据要记录前后快照。如果你的系统需要跨服务事务、又不想太动代码Seata AT是可以考虑的。5.3 选择建议场景推荐方案单体应用单数据库什么都不用本地事务够用微服务对一致性要求不高本地消息表 MQ最终一致微服务强一致要求高Seata AT 或 TCC金融级强一致低并发XA/2PC非核心数据可以容忍短暂不一致MQ异步 对账补偿分布式事务没有银弹。选型的核心不是哪个方案高级而是你的业务能容忍多大程度的不一致。6. 事务排查工具箱从日志到监控的一整套姿势事务的问题一旦出现往往都是线上的、隐性的、难复现的。所以一定要有一套预防和排查的手段而不是等出了问题再手忙脚乱。6.1 日志配置把事务边界打印出来Spring的事务日志默认是DEBUG级别不打开根本看不到。在application.yml里配置logging: level: org.springframework.transaction: DEBUG org.springframework.jdbc.datasource.DataSourceTransactionManager: DEBUG org.springframework.jdbc.datasource.JdbcTransactionManager: DEBUG打开后你会看到类似这样的日志Obtained JDBC transaction from DataSource [HikariDataSource (HikariPool-1)] Participating in existing transaction Initiating transaction commit Initiating transaction rollback这些日志的排列能帮你快速判断事务有没有开启、是新建还是复用、提交还是回滚、有没有因为rollback-only被强制回滚。6.2 ThreadLocal状态的运行时监控如果你怀疑某个方法执行时事务状态不对可以在代码里手动检测import org.springframework.transaction.support.TransactionSynchronizationManager; boolean isInTransaction TransactionSynchronizationManager.isActualTransactionActive(); System.out.println(当前是否在事务中: isInTransaction);isActualTransactionActive()返回true说明当前线程确实有数据库事务处于活动状态。如果外面标了Transactional但这里返回false说明代理没生效——自调用、final方法、私有方法逐个排查。还可以查看当前事务名Object name TransactionSynchronizationManager.getCurrentTransactionName();这能帮你快速定位当前事务是哪个方法开启的。6.3 监控事务耗时与连接占用事务另一个容易忽略的问题是连接泄漏和长事务。一个事务如果执行了几十秒连接就占用了几十秒连接池很快被打满。建议做法在DataSource层加慢SQL日志HikariCP有connectionTimeout、validationTimeout配置同时开启leakDetectionThreshold检测连接泄漏。用TransactionSynchronizationManager.registerSynchronization注册事务同步回调统计每个事务的耗时。Transactional public void bizMethod() { long start System.currentTimeMillis(); TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() { Override public void afterCompletion(int status) { long cost System.currentTimeMillis() - start; if (cost 1000) { log.warn(事务耗时过长: {}ms, status{}, cost, status); } } }); }这个方法能精确定位哪个事务方法最耗时但它需要每一个业务方法都加一遍侵入性强。更好的方案是写一个AOP切面统一拦截Transactional方法做耗时统计。6.4 事务失效排查的标准操作流程如果线上出现了疑似事务失效的问题我的排查顺序是这样的看日志打开事务DEBUG日志确认方法执行时有没有Obtained JDBC Transaction记录。没有就是代理没生效走第2步有就继续看提交/回滚记录走第5步。看方法签名是不是public类或方法有没有final看调用方是不是同一个类内部调用是不是没有被Spring管理的对象比如new出来的看注解Transactional有没有写对rollbackFor有没有配多数据源下transactionManager指对了没有看异常异常有没有被try-catch吞掉异常类型是不是RuntimeException看数据库表引擎支不支持事务连接是不是走到了正确的DataSource这套流程走一遍90%的事务问题都能定位。7. 最后的实战建议事务规范从我做起写到这里我把这些年跟事务打交道沉淀下来的几条规矩放在最后算是个人的实战总结也是新项目启动时的检查清单。事务方法要短小精悍。事务范围之内不要做远程调用、不要做复杂的文件IO、不要进行大批量循环。否则连接池迟早被打死。把非数据库操作移到事务外或者拆成多个事务块。事务边界要尽可能晚开启尽可能早提交。前置校验、参数组装这些放事务外真正需要数据库原子性的操作才放进事务块。很多人习惯方法一进来就开事务其实很多操作根本不需要事务保护。回滚配置要显式写。Transactional(rollbackFor Exception.class)这行字虽然啰嗦但它能挡住95%的回滚失效问题。自定义的业务异常统一继承RuntimeException省得每个方法都要考虑这个异常会不会回滚。批量处理用TransactionTemplate而不是Transactional。循环里的事务一定要用编程式事务精确控制粒度Transactional包整个循环就是把数据库往死里逼。分布式事务不要贪多求全。能靠业务流程设计规避的就尽量规避比如通过本地消息表做最终一致性比引入一套重量级分布式事务框架划算得多。选型之前先想清楚你的数据不一致容忍度。事务这个东西说到底是数据库连接和错误处理时机的管理艺术。理解底层机制比背多少面试题都管用。希望这篇文章里踩过的坑、总结的思路能让你少走几条弯路。
阅读完成 · 觉得有帮助？
