企业官网建设流程全解析

去年给一个新交易后台做技术选型时，我遇到了一个“不上不下”的难题：业务链路需要异步解耦，但日均消息量只有百万级左右，团队也拿不出专人去运维一整套重量级消息队列。如果硬上 Kafka 或者 RocketMQ，光集群节点、主题分区和监控告警就够我们几个后端忙活一整周。要是不上消息队列，订单创建、券发放、库存同步这些逻辑全都写在一条调用链里，每次活动一抖动，整条链路跟着雪崩。后来我把 XXL-MQ 列进了调研清单，才真正意识到轻量级分布式消息队列在中小业务场景里有多合适。这篇文章就是一份基于我个人落地经验整理的 XXL-MQ 使用手册，会从部署、接入、重复消费、分布式事务配合到选型对比全部过一遍，给正在做同样选型的后端同学一个可以直接参考的答案。

我先把结论放在前面：XXL-MQ 不是要取代 Kafka、RabbitMQ 这类重型中间件，它解决的是“业务量没大到需要专门团队维护消息集群，但异步解耦需求又真实存在”的夹心层场景。如果你的团队规模不大、运维人力紧张、业务消息量在百万到千万级，又希望消息队列能像普通 Java 应用一样一启动就能用，那这篇文章大概率能帮你省掉一整周的调研时间。

1. XXL-MQ 解决的问题：中等规模流量的异步解耦

1.1 大而全中间件在中小业务里的尴尬

很多团队在上消息队列之前，根本没想清楚自己的真实需求。下单要发通知、支付成功要触发后续流程、库存要同步、订单状态要回写，这些场景确实需要消息队列，但消息量远没到“海量”的程度。引入 Kafka 意味着引入 ZooKeeper 或 KRaft 模式、分区分配、副本同步、消费者组再平衡这一整套概念；引入 RocketMQ 则要考虑 NameServer、Broker 集群、主从同步和事务消息的部署方式。一个四个人的后端小组，要在一两周内把这些组件全部运维起来，还要保证高可用，压力非常大。

我自己见过不止一个团队，Kafka 集群搭起来了，但没人能说清楚分区数为什么是 24、副本因子为什么是 3，消费者再平衡导致消费延迟时也不知道去哪里看。最后问题根本不在消息队列本身，而是运维知识没跟上。XXL-MQ 这类轻量级方案的价值恰恰在这里：把“消息集群运维”这件事压缩到“维护一张表、启动一个 Java 服务”的量级。

1.2 XXL-MQ 的设计取舍：数据库即队列、控制台即管理

我理解 XXL-MQ 的核心设计思路只有一句话：用数据库存消息，用 HTTP 接口收发消息，用控制台管消息。它的服务端不依赖额外的消息存储组件，消息记录直接落在 MySQL 里；生产者和消费者通过 HTTP 请求与服务端交互，天然跨语言；管理后台提供可视化界面，可以看积压、看失败、手动触发重投。

这个设计带来的直接好处是排障路径非常短。消息发出去了没消费？打开数据库查状态就清楚了。消费失败了？后台能看到失败记录和重试次数。一个消息从生产到消费经历了哪些状态，每一步都看得见摸得着。相比黑盒化的消息集群，这种方式对中小团队极其友好。

1.3 适合放到 XXL-MQ 下面的三类典型场景

从我实际使用的经验看，有三类场景放 XXL-MQ 非常合适。第一类是业务事件通知，比如订单支付成功后的发券、发短信、更新积分，这类消息对吞吐要求不高，但对可靠性和可观测性要求高。第二类是数据同步复制，比如把订单数据从交易库同步到分析库，或者把用户状态变更同步到搜索索引，量级不大但丢不得。第三类是削峰填谷，比如秒杀场景里把库存扣减请求先写入消息队列，再由消费端按数据库能承受的速率慢慢处理。

但有一点要明确：XXL-MQ 不适合承接海量日志、埋点流这类动辄每秒几十万条写入的场景。数据库存储天然限制了它的吞吐上限，硬要拿它做日志管道，会把数据库直接打爆。认清边界，比硬撑功能更重要。

2. 核心架构与消息生命周期：从投递到确认的完整链路

2.1 最小架构单元：服务端、管理端与客户端

XXL-MQ 的部署模型不复杂。服务端是核心节点，负责接收生产者的发送请求、存储消息、调度消费、记录消费结果；管理端通常和服务端一体化部署，提供 Web 界面供运维人员查看队列状态；客户端是业务侧接入用的 SDK，生产者通过它把消息发送到服务端，消费者通过它拉取或者接收消息并回传确认结果。

客户端和服务端的通信走 HTTP，这一点很关键。相比 AMQP 这种复杂协议，HTTP 的调试成本低，curl 就能模拟生产者和消费者，出现问题时抓请求日志就能定位。而且 HTTP 跨语言支持好，Java、Go、Python 都能很方便地对接，不用为了某一个语言生态绑定整个技术栈。

2.2 以状态机视角理解消息流转

在使用 XXL-MQ 时，理解消息状态流转比死记 API 更重要。我落地时习惯把消息状态抽象为四段：初始化、处理中、成功、失败。生产端把消息发送到服务端，服务端落库后消息进入初始化状态，等待消费者领取；消费者请求消息时，服务端把对应消息标记为处理中，同时把消息数据返回给消费者；消费者业务逻辑执行成功后，回传确认，服务端把消息标记为成功；如果消费者明确返回失败，或者超过确认超时时间没有应答，服务端会把消息重新放回待消费队列等待重试。

这条链路和大多数消息队列的 ack 机制是同一个道理，只是实现上更直观。每次状态变更都能在数据库里看到，甚至可以写一个定时任务把积压超过阈值的数据捞出来告警。对运维人员来说，这种“白盒”体验是重量级消息集群很难给的。

2.3 为什么采用基于拉取模式的消费调度

XXL-MQ 的消费调度，我理解更偏向拉取模型设计。消费者向服务端发起拉取请求，服务端把可消费消息返回给消费者。这个设计的隐藏优势是消费者宕机时不会给服务端造成额外压力——不像推送模式那样服务端还要维护连接状态、处理消费端失联重推。

另一个好处是消费速率可控制。消费者可以根据自身业务处理能力调节拉取频率和批量大小，后端数据库压力大的时候，消费端把拉取间隔调大一点，就实现了天然背压。我在活动高峰期就经常用这个特性，把非核心消息的拉取间隔从每秒一次改成每五秒一次，数据库瞬间就稳了。

2.4 轻量级不等于随便用：真实容量边界

轻量级是把双刃剑。数据库存储意味着消息读写都在和业务共用的数据库实例上分享资源。我实际压测下来，单表结构下每秒处理几千条消息没问题，但要冲到每秒几万条，就会明显感觉到数据库 IO 压力。所以我的建议是：给 XXL-MQ 准备独立的数据库实例，至少独立表空间，不要和核心业务库混在一起。消息表的数据也要定期归档清理，否则时间一长，索引膨胀、查询退化，消费延迟会越来越大。

3. 部署手册：数据库初始化与服务端配置

3.1 建表脚本与索引设计

XXL-MQ 部署的第一步是初始化数据库。下面这个建表结构是我项目里实际落地的形态，和官方 release 包里提供的脚本大方向一致，具体字段名以你下载到的版本为准。核心要把握好三个字段：状态字段、重试次数字段、允许执行时间字段，这三个字段决定了消息能否被正确消费、何时被重试。

CREATE TABLE `xxl_mq_message` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '消息唯一ID', `topic` varchar(128) NOT NULL COMMENT '消息主题', `group_name` varchar(128) DEFAULT NULL COMMENT '消费者分组', `data` text NOT NULL COMMENT '消息体，通常是JSON', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0待消费，1处理中，2成功，3失败', `retry_count` int(11) NOT NULL DEFAULT '0' COMMENT '已重试次数', `max_retry_count` int(11) NOT NULL DEFAULT '3' COMMENT '最大重试次数', `next_execute_time` datetime DEFAULT NULL COMMENT '下次可执行时间', `create_time` datetime NOT NULL, `update_time` datetime NOT NULL, PRIMARY KEY (`id`), KEY `idx_topic_status` (`topic`,`status`), KEY `idx_next_execute_time` (`next_execute_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='MQ消息表';

索引设计有一个容易踩的坑：不要只给 topic 建索引，要把 topic 和 status 建联合索引。因为消费者拉取消息时，最频繁的查询条件就是“某个主题下状态为待消费且到达执行时间的消息”，联合索引能让这个查询走索引而不是全表扫描。next_execute_time 单独建索引也很重要，重试消息扫描时这个条件是必带的。

3.2 服务端配置项逐一说明

服务端启动前要改的配置，我归纳下来主要是四块：数据库连接、HTTP 服务端口、访问令牌、线程池参数。数据库连接不用多说，HTTP 端口要确保业务服务器能访问到；访问令牌是生产端和消费端连接服务端时的凭证，默认值一定要改，不然有安全风险；线程池参数决定了服务端处理并发请求的能力，小团队先按默认值跑即可，出现性能瓶颈再调。

xxl: mq: admin-address: http://127.0.0.1:8080/xxl-mq access-token: your-access-token db: url: jdbc:mysql://127.0.0.1:3306/xxl_mq?useUnicode=true&characterEncoding=UTF-8 username: xxl_mq_user password: change-me thread: biz-thread-pool-size: 32

3.3 启动、健康检查与常见启动故障

配置改完后，启动服务端和启动普通 Spring Boot 应用没有区别。启动成功的标志是看到 admin 地址对应的页面能正常打开。我建议启动后第一件事是确认三件事：数据库连接是否正常、访问令牌是否匹配、服务器时间是否准确。服务器时间不准这个坑很隐蔽，消息的 next_execute_time 依赖系统时间，如果服务器时间慢了几分钟，所有消息都会晚几分钟才被消费。

3.4 如何实现双机部署

XXL-MQ 本身支持多服务端节点部署，底层因为消息都落在共享数据库里，所以多个服务端节点只要指向同一个数据库，就能协同工作。生产端的请求随便打到哪个节点都行，消费端从哪个节点拉取消息也都能拿到数据。

不过这句话得反过来理解：服务端多节点部署解决了应用层的高可用，但数据库仍然是单点。如果消息队列对可用性要求很高，数据库层就得做主从复制，服务端连接主库，主库故障时切换到从库。我建议中小团队先把数据库主从做好，服务端部署两个节点挂在负载均衡后面，这个方案已经能满足绝大多数场景。

4. 客户端接入：生产者与消费者的代码路径

4.1 生产者 API 与发送模型

生产者接入时，我常用的方式是先初始化一个生产者客户端，配置好服务端地址和访问令牌，然后通过客户端发送 MqMessage 对象。下面这段代码是常规接入形态，具体包名和方法签名以你使用的版本为准。

// 初始化生产者 XxlMqProducer producer = new XxlMqProducer(); producer.setServerAddress("http://127.0.0.1:8080/xxl-mq"); producer.setAccessToken("your-access-token"); producer.init(); // 构造消息并发送 MqMessage message = new MqMessage(); message.setTopic("order-paid-event"); message.setData(JSONObject.toJSONString(orderPaidEvent)); producer.send(message);

发送模型上有一点值得注意：send 方法默认是同步确认的，服务端把消息成功落库后才返回成功。如果服务端返回超时，业务方不能确定消息到底有没有落库，这时候宁可重复发送一条，也不要丢弃。重复消息可以由消费者端做幂等处理兜底，这个我在后面专门讲。

4.2 消费者 API 与消费结果确认

消费者接入的常规方式是实现一个消费接口，在方法上指定要消费的 topic 和分组。服务端把消息数据传给该方法，业务逻辑处理完后，返回成功或失败标识，客户端把这个标识回传给服务端，完成一次完整的消费确认。

public class OrderPaidEventConsumer implements XxlMqConsumer { @Override @XxlMqConsumer(topic = "order-paid-event", group = "order-service") public MqConsumeResult consume(MqMessage message) { try { // 1. 解析消息体 // 2. 处理业务，例如更新订单状态、发券、发短信 // 3. 返回成功，服务端将消息标记为已完成 return MqConsumeResult.success(); } catch (Exception e) { // 返回失败，服务端会触发重试 return MqConsumeResult.fail("消费异常"); } } }

这里我想强调一个容易理解错的地方：消费者方法返回成功，不代表业务一定成功；它只代表这个消费者认为这条消息已经被处理掉了。如果业务逻辑在返回成功之前崩溃了，这条消息就不会被重试。所以在消费逻辑里，要把“标记成功”放在所有关键业务操作完成后，不要急着 return。

4.3 命名习惯、消费者分组与并发配置

消息队列用久了，命名习惯会直接影响排障效率。我建议 topic 命名统一用“业务域-事件名”的格式，比如 order-paid-event、stock-deducted-event；consumer group 用“服务名”来命名，比如 order-service、stock-service。这样在管理后台看到积压时，一眼就知道是哪个服务的哪个消费者没跟上。

并发配置上，消费者端可以设置拉取线程数和批量大小。批量拉取能显著降低请求次数，但也意味着一条消息处理失败时，同一批的其他消息状态管理会变复杂。我通常把批量大小控制在 10 以内，既能减少 HTTP 请求次数，又不会因为单条失败拖累整批消息。

4.4 处理失败时的三种选择

消费者处理消息失败时，常见做法有三种：直接返回失败让服务端重试、捕获异常后记入本地失败表、把消息转发到专门的重试 topic。第一种最简单，但要注意设置最大重试次数，否则极端情况下消息会无限循环重试。第二种适合需要人工介入的业务，失败了先记录，定时任务扫出来再处理。第三种适合区分不同失败原因的场景，比如参数错误永远不会成功，那就没必要反复重试，直接转入死信队列人工处理。

5. 重复消费的应对：消息确认机制之外的幂等设计

5.1 重复消费到底是怎么发生的

重复消费是消息队列绕不开的话题，XXL-MQ 也一样。最典型的场景是：消费者拿到了消息，业务逻辑处理完成，但是在回传成功确认时网络超时了。服务端没收到确认，认为这条消息没有被成功消费，于是重新投递。消费者再拿到的就是同一条消息，同一笔订单被处理了两次。

还有一种是业务逻辑超时。消费者处理耗时超过了服务端设置的确认超时时间，服务端提前把消息标记为待重试，但此时业务线程还在继续执行，最终这条消息被两个线程同时处理。理解了这两个场景就会明白，靠消息队列自身保证“只消费一次”是不现实的，能做到“至少一次投递”已经很好了，真正的“只处理一次”必须在业务侧实现幂等。

5.2 消费者侧幂等三件套：唯一键、状态机、分布式锁

我在生产环境里做幂等，最常用的三件套是：数据库唯一索引、业务状态机、分布式锁。

数据库唯一索引是最硬的保证。处理消息前，先把消息 ID 对应的业务记录插入一张消费记录表，唯一索引保证同一条消息只能插入一次，插入成功才继续业务处理，插入失败说明已经处理过直接跳过。这个方案的缺点是会在业务表之外多一张记录表，但换来的是最可靠的幂等。

业务状态机适合业务本身有明确状态的场景。比如订单状态只有“待支付”才能变成“已支付”，“已支付”不能再次变成“已支付”。即使消息被重复消费，第二次执行时发现状态不匹配，直接跳过即可。这个方案不需要额外表，但对业务建模有要求。

分布式锁适合处理并发场景下的重复消息。比如同一个订单的库存扣减消息同时来了两条，先用订单号作为锁 key 加分布式锁，拿到锁才执行，没拿到锁就丢弃。注意锁要有合理的过期时间，防止消费线程崩溃导致锁无法释放。

5.3 幂等性与业务异常要分开处理

有一个边界特别容易混淆：幂等跳过和业务失败不能混在一起。如果一条消息因为“业务数据不存在”被跳过，那是业务问题，要告警；如果因为“重复消费被幂等拦截”，那是正常情况，不需要告警。我建议在幂等判断代码里明确打日志，加上 msgId 和业务单号，这样排查问题时才能快速区分是重复还是异常。

5.4 消费失败进入死信状态后怎么办

超过最大重试次数的消息会进入失败状态，也就是通常说的死信。XXL-MQ 里这些消息会在管理后台显示出来。我的经验是不要等着人工去后台翻，而要写一个定时任务定时捞取死信消息，发送到告警群，同时把消息内容持久化到一张专门的问题表里，方便事后补单。如果不做这一步，死信消息躺在后台无人问津，业务影响只能在用户投诉时暴露出来。

6. 与分布式事务、分布式缓存的组合实践

6.1 本地消息表配合 XXL-MQ 的可靠投递模式

消息队列经常被用来解决分布式事务，确切地说是分布式事务里的最终一致性。一个经典实践是本地消息表模式：业务操作和消息记录放在同一个本地事务里，业务成功提交，消息记录也成功写入；然后通过一个后台任务把消息记录中的事件发送到 XXL-MQ，发送成功后再更新消息记录的状态。这个模式的好处是消息不会丢，因为业务事务和消息记录要么一起成功要么一起失败。

以订单支付为例：订单服务在自己的数据库里开启事务，更新订单状态为已支付，同时插入一条 outbox 事件记录“订单已支付”，事务提交。后台定时任务读取未发送的 outbox 记录，通过 XXL-MQ 生产者发送到 order-paid-event 主题，发送成功把记录标记为已发送。库存服务消费这个消息，执行库存扣减。

6.2 订单与库存更新这种经典场景的落地流程

订单和库存是分布式事务的经典场景。流程拆开来看是这样的：下单请求先扣减本地库存或锁定库存，生成支付事件；支付成功后通知库存服务真正扣减库存；如果扣减失败，消息触发重试，直到成功或者进入死信人工处理。这里要格外注意库存扣减的幂等设计，否则同一个订单重复扣库存会造成超卖。

我这里再补充一个实用的细节：库存扣减事件里最好带上唯一的业务幂等键，通常是订单号和商品号的组合。消费端在扣减库存前先查一下操作记录表，如果该订单已经扣过库存就直接跳过。照片贴出这段逻辑的代码结构：

String idempotentKey = orderId + ":" + skuId; if (deductRecordExist(idempotentKey)) { log.info("重复库存扣减事件，跳过，key={}", idempotentKey); return MqConsumeResult.success(); } // 执行库存扣减 // 写入扣减记录表，幂等键加唯一索引

6.3 通过 MQ 做缓存一致性刷新

缓存一致性是另一个高频使用场景。用户修改了资料，数据库更新成功了，但缓存里还是旧数据，怎么办？常规做法是更新数据库后直接删除缓存，但如果删除失败就会出现长时间的脏数据。更稳妥的做法是更新数据库后发送一条缓存刷新事件，消费者收到事件后删除缓存或更新缓存，如果删除失败就重试，直到成功。

这里有个细节：缓存刷新事件消费失败重试时，有可能数据已经被更新第二次了。所以缓存刷新消费者里也要做版本比较，比如事件里带上数据版本号，缓存更新时只有当版本号比当前缓存大才覆盖，避免旧数据覆盖新数据的问题。

6.4 分布式环境下锁、事务、消息的顺序关系

把分布式锁、分布式事务、消息队列放在一起看时，顺序问题很容易踩坑。我个人的原则是：先写业务数据，再执行锁操作，最后确认消息。具体到消费者里就是：先从数据库确认幂等，然后加分布式锁，接着处理业务，处理完释放锁，最后返回消费成功。如果先返回成功再处理业务，一旦业务失败这条消息就不会被重试；如果先加锁再查幂等，并发情况下第二个线程会被阻塞在锁上，白白等待。

7. 选型对比：XXL-MQ、Kafka、RabbitMQ、RocketMQ 怎么选

7.1 核心选型对比表

很多文章喜欢列性能数据，但我觉得选型对比更重要的是看模型差异和运维成本。下面这个表是我给团队做分享时用的，不一定覆盖全部维度，但足够帮助快速决策。

表格里的“单机吞吐量”是量级不是精确值，实际上参数调优、硬件规格都会影响结果。我更想强调的是运维复杂度这一行：XXL-MQ 的下限是最低的一个，一个小团队完全能 hold 住。

7.2 选型不只是看性能，人效也要算进去

选型时不能只看性能指标，还要算团队人效。Kafka 性能再好，如果团队里没人真正理解消费者再平衡和日志清理机制，出故障时照样抓瞎。我见过一个团队，Kafka 集群磁盘被日志占满，消费积压了十几万条，最后靠临时扩容才救回来。这种事情在 XXL-MQ 上基本不会发生，因为消息都在数据库里，积压量直接在后台看到，清理也简单。

这里要说句公道话：XXL-MQ 的定位是“够用且可控”，它的优势不在峰值性能，而在故障的可诊断性和运维的低门槛。项目早期或者团队经验不足时，用一个可控的方案换取业务快速迭代，是性价比很高的选择。

7.3 什么情况下不适合用轻量级中间件

我也得把丑话说在前面。如果业务消息量日均超过千万级，每秒峰值写入超过几万条，这时候轻量级方案会让数据库承受巨大压力，应该直接考虑 Kafka 或 RocketMQ。如果业务对消息顺序性有强依赖，比如同一个用户的操作必须严格按照时间顺序处理，XXL-MQ 的数据库模型实现顺序消费会比较别扭，不如 Kafka 单分区来得直接。如果要用消息队列做流式计算、实时数仓管道，那更不用想了，Kafka Streams 或 Flink 才是正确的方向。

7.4 从轻量级向重量级迁移的扩展策略

用了轻量级方案不意味着永远绑死。我在设计消息生产者和消费者时有一个习惯：业务代码层面抽象一层，不直接依赖具体的 MQ 客户端 API。这样万一未来消息量暴涨需要迁移到 Kafka，只需要把生产者和消费者的实现类替换掉，业务逻辑不用动。这种“为迁移留后路”的设计思路，比任何一次性的选型判断都更重要。

8. 实操避坑清单：围绕 XXL-MQ 的几个真实教训

8.1 消息 ID 要贯穿业务日志，便于全链路排查

刚开始用 XXL-MQ 时，我遇到一个棘手的线上问题：消息消费失败，但业务日志里没有消息 ID，根本没法定位是哪条消息。后来养成了一个习惯：消费者方法第一行就打印日志，内容包含消息 ID、topic、关键业务单号。配合服务端日志，一条消息从生产到消费的完整链路就清晰了。这个习惯对任何消息队列都适用，但在轻量级方案里更容易坚持，因为日志链路短，排查起来很快。

8.2 确认超时时间和重试次数要一起调优

确认超时时间默认值不一定适合所有业务。如果一个消费者处理一条消息通常要 30 秒，但超时时间只有 10 秒，那所有消息都会走向重试，消费成功率会非常难看。我的建议是先统计业务处理耗时的 p99 值，把确认超时设成 p99 的两倍以上。重试次数也不要一概而论，建议配置成“重复处理不产生副作用”的业务可以多设几次，比如 5 次以上；对副作用明显的业务，比如扣减库存、发放奖励，控制在 3 次以内，更多转到人工处理。

8.3 消费线程与业务线程池要分离

消费者拉取消息的线程和执行业务逻辑的线程最好分开。拉取线程要保持快速响应，如果业务执行阻塞在拉取线程上，整个消费者的吞吐会被拖垮。我实际用过的方式是消费者处理器里把任务丢给一个独立的线程池执行，主线程立刻返回；业务线程池设置队列上限，队列满了就返回失败，让消息留在服务端继续重试。这种设计能防止业务慢查询反过来拖垮消息拉取能力。

8.4 消息表要定期归档，索引要监控

消息表只增不减是消息队列的老大难问题。消费成功的消息如果一直留在表里，索引会膨胀，查询效率越来越差。我建议分区或按时间归档，每天把三天前已经消费成功的消息移动到归档表。归档表可以建得更宽，方便事后分析；热表只保留近期活跃数据，查询和写入性能都能保持稳定。这个运维动作看起来繁琐，但真能避免“消息延迟越来越高，数据库 CPU 莫名飙升”的诡异问题。

8.5 管理后台的使用习惯

管理后台除了看积压，还要养成定期看失败消息、重试消息的习惯。我每次上线新消费者都会盯几小时后台，重点观察：消费失败率是否有波动、重试次数是否异常上升、消息积压是否在活动结束后回落。这三项指标能提前暴露消费者代码的潜在 bug，比如数据格式不兼容、依赖的服务超时等。等到用户投诉才去看后台，性质就变了。

这套体系我现在已经稳定跑了两个季度。最大的体会是：轻量级方案要求使用者心里有数——知道它适合什么、不适合什么，把幂等做好、把确认机制看明白，它就是一个非常趁手的工具。尤其是团队规模不大的时候，省下来的运维精力能全部投入到业务实现上。最后再分享一个小经验：不管选什么消息队列，消息结构和幂等键设计一定要提前定好，这两件事后期改起来成本极高，比选型本身还重要。