企业官网建设流程全解析

聊到CI/CD优化，很多人第一反应是压缩流水线时间：并行执行、缓存依赖、精简镜像。我做了几年持续交付落地，发现真正拖垮交付效率的，往往不是流水线本身，而是下游那个不起眼的“接收站”——测试环境管理。代码构建从10分钟压到了3分钟，结果开发把镜像推到测试环境后，环境起不来、数据库被污染、多个人抢同一个环境，最后还是得花一两个小时手动收拾。CI/CD优化做到最后，瓶颈全在这里。

测试环境管理这件事，说白了就一句话：让正确的人，在正确的环境版本上，用正确的数据，验证正确的代码。听起来简单，做起来特别容易失控。这篇文章不聊虚的，直接拆解我在真实项目里沉淀下来的策略、架构和踩坑记录，重点讲怎么用GitLab CI/CD和Docker Engine把测试环境管起来，顺便拿RuoYi这类Java后台管理系统做一个完整落地示例。

1. 测试环境管理的核心矛盾：为什么CI/CD越快，环境越拖后腿

1.1 测试环境在CI/CD流水线中的真实定位

先看一条典型的交付流水线：代码提交、静态检查、单元测试、构建镜像、推送制品、部署到测试环境、执行接口测试或手工验证。前几个环节都是纯计算，机器多跑几轮就完事。到了“部署到测试环境”这一步，突然就变成了物理世界的问题——你得有机器、有网络、有数据库、有配置、有端口、有依赖服务。

测试环境在流水线里的真实定位，是“构建产物与质量验证之间的转换层”。它接收上游交付的镜像，为下游验证提供可运行的系统。这个转换层一旦不稳定，后面的测试工作全部失去意义。自动化测试跑得再快，环境没起来也只能失败重试；测试人员能力再强，数据乱糟糟也没法判断是不是代码缺陷。

我习惯用一个类比：流水线优化就像把高速公路上的车都换成跑车，但当所有车汇入同一个收费站——测试环境——跑车也得排队。收费站服务能力跟不上，车速再快也没用。CI/CD的吞吐量上限，很多时候不是流水线本身，而是测试环境这个“收费站”的供给能力。

1.2 环境混乱的连锁反应：从“环境挂了”到“交付延期”

测试环境管理混乱，不是简单的一句“环境不好用”就能概括的，它会产生一串连锁反应。

最直接的症状是“坏境”。测试人员早上来，登录系统，发现接口500，数据库连不上。于是找开发：环境是不是挂了？开发上去一看，说我没动啊。折腾半小时，发现是昨晚另一个同事部署了新版本，改了数据库配置，顺手把数据表结构迁移了一版，把旧数据搞坏了。这种“环境漂移”问题，在多人共用一套环境时几乎天天发生。

第二个症状是“抢环境”。多个业务并行开发，都在同一套测试环境上测试。A业务部署了，B业务一测发现功能不对，因为前端页面已经被A业务的分支覆盖了。两个团队互相怀疑，最后只能约定时间段轮流用，交付节奏直接被拖乱。

第三个症状是“数据污染”。测试人员跑一个“下单”用例，往数据库里写了几百条脏数据，第二天另一个测试跑“订单列表”，查出来一堆垃圾数据，断言全失败。没人敢清理，因为不知道哪些是真数据、哪些是脏数据。

这些症状叠加起来，最终结果只有一个：交付延期。给领导汇报的时候不能说“因为环境不好所以延期”，听上去像个借口，但其实这就是真实原因。环境管理做不好，是在用团队最宝贵的人力，反复消耗在低级问题上。

1.3 环境管理问题的成本估算与优化优先级

为了说服团队投入测试环境治理，我算过一笔账，建议你也算一下自己团队的成本。

假设一个10人团队，人均成本按行业内中间值估算，每天工作时长8小时。如果因为测试环境不稳定，平均每天每人要花30分钟等待环境修复或重试部署，那么一天就是5人时，一个月22个工作日就是110人时。110人时乘以人力成本，乘以12个月，一年下来相当可观。更别提这期间测试空转、开发被迫中断、缺陷漏到上线后返工的成本。

关键是，这笔钱花得特别冤。测试环境管理不是新技术问题，而是工程管理问题。工具和方案都是现成的：容器化让环境创建销毁变得廉价，CI/CD让部署流程可编排，基础架构即代码让环境配置不再漂移。缺的是把这些能力系统化组合起来，形成一套清晰的策略。

我的判断是：测试环境管理在CI/CD优化里的优先级，应该排在“压缩构建时间”之前。构建快了但没有稳定环境接收，等于前面省的时间在门口排队。先把环境稳定性和供给速度做起来，再回头压流水线耗时，效果会好很多。

2. 优化测试环境管理的四个关键策略

这一节我提炼了四个策略，都是我实际执行过并且验证有效的。不是理论推演，不是工具拼盘，而是从“为什么会乱”反推出来的治理框架。

2.1 环境即代码：用声明式配置消除“环境玄学”

测试环境管理最大的敌人，是“环境玄学”。开发说“我本地跑得好好的”，运维说“服务器上确实有问题”，两边都觉得自己没错。最后发现，测试环境里某些软件包是两年前装的，某个配置文件被谁手工改过，某个端口被其他服务占了。这些环境状态都没有记录，出了问题无从查起。

解法就是“环境即代码”，把环境的一切定义用代码管理起来，纳入Git版本控制。镜像用Dockerfile定义，服务编排用docker-compose.yml定义，配置项通过环境变量注入，初始化数据用SQL脚本管理。

这样一来，环境不再是某个人脑中的操作流程，而是一堆有版本号的文件。任何人想复现环境，只需要把代码仓库拉到对应分支，执行一份声明式配置，就能得到完全一致的结果。环境漂移被连根拔起。

这里要特别强调：环境模板不能是“差不多能用就行”，必须和生产保持同构。比如生产用的MySQL 8.0，测试环境就不要用5.7；生产用Redis 6，测试环境也保持一致。版本差异导致的兼容性问题，最容易在“测试通过、上线炸锅”的环节暴露，必须在源头堵住。

2.2 动态环境按需创建与生命周期治理

传统做法是长期维护一套固定的测试环境，所有人共用。问题前面说过，互相踩踏。我现在更倾向于推荐“动态环境”模式：每提交一个MR或每个分支，动态创建一个完全独立的测试环境，用完后自动销毁。

动态环境的底层逻辑，是让环境成为流水线的一个临时产物。代码里用GitLab CI/CD的environment功能，结合git branch和commit，可以给每个环境起唯一的名称。这样一个MR对应一个URL，测试人员直接点链接就能看，互不干扰。

有人会担心动态环境资源消耗太大。这个担忧以前合理，但现在容器化普及后，创建一套环境只是拉几个容器的事，成本很低。而且大部分动态环境并不需要长期存在，占用的资源可以在MR合并或分支删除后释放。资源做到“用多少拿多少”，整体开销反而比长期环境更可控。

生命周期治理是容易被忽视的部分。环境不仅要创建，还要销毁。我见过有人开了几十个动态环境忘了关，服务器资源被吃光。所以环境必须有“生命周期”：设置TTL，超时自动回收；环境和分支绑定，分支删除时环境一并销毁；定期巡检，把失联环境列为待清理项。这一条务必纳入自动化，靠人自觉不靠谱。

2.3 数据隔离与基线数据治理

测试环境里的数据，是第二头疼的问题。动态环境解决的是“多人共用环境”的矛盾，但哪怕一个人单独用一套环境，数据污染照样能让测试结果失真。

我把数据治理分成两层：第一层是“数据隔离”，第二层是“基线数据管理”。

数据隔离，指的是不同环境之间数据物理隔离。动态环境天然满足这一点——每个环境配独立的数据库实例或独立的database/schema。最怕的是多个环境共享一套数据库，测试用例一跑，数据互相污染。

基线数据管理，指的是环境初始化时，加载一套固定的、可预期的数据库数据。这套数据要覆盖核心业务场景，比如一个商城系统，至少要有几个用户、几件商品、一张待支付订单。数据量不能太大，够测试用就行。测试用例执行时，如果改动数据，应在用例结束后回滚或重置，保证基线数据的完整性。

实际执行时，基线SQL脚本也要纳入Git管理。每次环境创建时自动执行，而不是靠某个人手工导入。数据库表结构变更时，基线脚本同步更新。这样环境在哪个commit上创建，数据就是那一刻的规范状态，可复现、可追溯。

2.4 环境一致性设计：向生产环境“靠拢”而非“模仿”

测试环境和生产环境不一致，是线上事故的温床。常见情况是：生产环境有4个服务节点，测试环境只有1个；生产环境有消息队列，测试环境没装；生产环境用的云数据库，测试环境用本地SQLite。结果很多问题在测试环境根本发现不了，上线就暴露。

环境一致性的原则，我总结为八个字：同构不同量，靠拢不模仿。同构是指技术栈、中间件、基础组件版本保持一致；不同量是指资源规格、副本数量可以缩容。比如生产是MySQL 8.0主从架构，测试环境可以用单节点MySQL 8.0，但版本不能变成MariaDB或MySQL 5.7。生产有RabbitMQ，测试环境也要有，即使只是单实例。

靠拢不模仿的意思是，测试环境不必完全复刻生产规模，但关键行为要一致。比如生产环境配置了Redis缓存，测试环境不能省略缓存，否则缓存相关bug测不出来。生产环境开启了HTTPS，测试环境也最好用同一套证书签发逻辑，别用HTTP混过去。

一致性设计的价值，是让测试结果更可信。开发在测试环境验证过的功能，到了生产不会因为环境差异重新返工。这一点对CI/CD优化是决定性的——只有环境可信，自动化测试的结论才有意义。

3. 实操：用GitLab CI/CD与Docker Engine搭建测试环境管理流程

策略讲完，进入实操环节。我用一套相对通用的方案做演示：GitLab作为代码托管和CI/CD平台，GitLab Runner使用Docker executor执行任务，Docker Engine作为运行环境，docker-compose编排服务。部署目标为一个RuoYi前后端分离项目。这套方案也就是说热搜词里反复出现的“GitLab CI/CD + Docker Engine”的那条主线。

3.1 整体架构与工具选型

先讲清楚架构，否则后面的代码片段不好理解。

代码仓库里同时包含应用代码和部署文件。开发推送代码到GitLab，触发Pipeline。流水线分为几个stage：build、deploy、test、cleanup。build阶段用Docker构建后端镜像，推到GitLab Registry。deploy阶段通过SSH登录到测试环境服务器，拉取镜像，用docker-compose启动一组服务。test阶段执行接口测试脚本。cleanup阶段按需销毁环境。

为什么选GitLab Runner的Docker executor而不是Shell executor？因为Docker executor每次执行任务都会启动一个全新的容器，隔离性好，环境干净，不会出现“上次构建留下的残留影响这次构建”的问题。对CI/CD这种重复性极高的场景，环境干净是第一需求。

为什么部署环节不直接用docker exec而是走SSH？因为Runner可能运行在任意一台机器上，不一定要和部署服务器在同一台。为了让部署操作可代理、可审计，走到SSH是更通用的方案。后面代码示例里我会写清楚。

另外需要强调一个选型考量：这里没有引入Kubernetes，是有意为之。中小团队或单个业务线的测试环境，K8s的运维成本可能超过收益。Docker Compose足够表达多数服务依赖关系，学习门槛低，排障链路短。等团队规模和环境复杂度上来了，再迁移到K8s也不迟。

3.2 编写.gitlab-ci.yml实现环境动态创建与销毁

下面是一份可以直接参考的.gitlab-ci.yml示例。我加了注释，尽量让新手也看得懂。

stages: - build - deploy - test - cleanup variables: IMAGE_TAG: $CI_COMMIT_SHORT_SHA DEPLOY_SERVER: "test-env-server.example.com" PROJECT_NAME: "ruoyi-test" build-backend: stage: build image: docker:24.0.9 services: - docker:24.0.9-dind before_script: - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY" script: - docker build -t "$CI_REGISTRY_IMAGE/ruoyi-server:$IMAGE_TAG" ./ruoyi-server - docker push "$CI_REGISTRY_IMAGE/ruoyi-server:$IMAGE_TAG" rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' - if: '$CI_COMMIT_BRANCH == "develop"' deploy-test: stage: deploy image: alpine:3.19 before_script: - apk add --no-cache openssh-client script: - eval $(ssh-agent -s) - echo "$SSH_PRIVATE_KEY" | ssh-add - - ssh -o StrictHostKeyChecking=no root@$DEPLOY_SERVER " export DOCKER_TAG=$IMAGE_TAG && export ENV_NAME=test-$CI_COMMIT_REF_SLUG && export MYSQL_DATABASE=ruoyi_$CI_COMMIT_REF_SLUG && docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY && docker compose -p $PROJECT_NAME-$CI_COMMIT_REF_SLUG -f docker-compose.test.yml up -d --pull always " environment: name: test/$CI_COMMIT_REF_SLUG url: http://test-$CI_COMMIT_REF_SLUG.example.com rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' - if: '$CI_COMMIT_BRANCH == "develop"' run-api-test: stage: test image: alpine:3.19 before_script: - apk add --no-cache curl script: - curl -f --retry 5 --retry-delay 10 http://test-$CI_COMMIT_REF_SLUG.example.com/ruoyi/health || exit 1 rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' - if: '$CI_COMMIT_BRANCH == "develop"' cleanup-environment: stage: cleanup image: alpine:3.19 before_script: - apk add --no-cache openssh-client script: - eval $(ssh-agent -s) - echo "$SSH_PRIVATE_KEY" | ssh-add - - ssh -o StrictHostKeyChecking=no root@$DEPLOY_SERVER " docker compose -p $PROJECT_NAME-$CI_COMMIT_REF_SLUG -f docker-compose.test.yml down --remove-orphans --volumes || true " environment: name: test/$CI_COMMIT_REF_SLUG action: stop rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' when: never - if: '$CI_COMMIT_BRANCH == "develop"' when: manual

几个关键点拆解一下。

build-backend里的服务声明，用的是DinD模式，即Docker in Docker。Runner在容器里跑，而构建镜像需要Docker守护进程，通过docker:dind服务解决。注意privileged模式一般还是要开启的，否则嵌套Docker创建容器时会报权限问题。

deploy-test通过SSH登录到部署服务器，把一个长命令交给远程shell执行。主要做四件事：声明环境变量、登录Registry、拉取最新镜像、用docker compose构建/更新服务。每次用的ENV_NAME和MYSQL_DATABASE都带上分支slug，这样每个分支一套独立环境、独立数据库，互不干扰。

cleanup-environment默认不自动执行，在merge request场景下会跳过销毁，因为MR合入后环境还要用于后续验证；在develop分支构建后，可以手工触发销毁已合并分支的环境。实际项目里根据团队习惯调整。

3.3 以RuoYi为例的部署参数设计与执行过程

RuoYi是常见的Spring Boot + Vue前后端分离项目，部署依赖MySQL和Redis，非常适合拿来做示例。下面是一份适用于测试环境的docker-compose.test.yml，做了明显的“测试环境最小化”配置。

version: "3.8" services: mysql: image: mysql:8.0.36 container_name: ruoyi-test-mysql environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:-test_root_123} MYSQL_DATABASE: ${MYSQL_DATABASE:-ruoyi_default} command: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_unicode_ci - --max-connections=200 - --innodb-buffer-pool-size=64M volumes: - ./sql/ruoyi.sql:/docker-entrypoint-initdb.d/ruoyi.sql:ro healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-proot"] interval: 5s timeout: 3s retries: 20 redis: image: redis:7.2.4 container_name: ruoyi-test-redis command: ["redis-server", "--maxmemory", "64mb", "--appendonly", "no"] healthcheck: test: ["CMD", "redis-cli", "ping"] interval: 5s timeout: 3s retries: 10 ruoyi-server: image: ${CI_REGISTRY_IMAGE}/ruoyi-server:${DOCKER_TAG} container_name: ruoyi-test-server depends_on: mysql: condition: service_healthy redis: condition: service_healthy environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/${MYSQL_DATABASE}?useSSL=false&serverTimezone=Asia/Shanghai SPRING_DATASOURCE_USERNAME: root SPRING_DATASOURCE_PASSWORD: ${MYSQL_ROOT_PASSWORD:-test_root_123} SPRING_DATA_REDIS_HOST: redis SPRING_DATA_REDIS_PORT: 6379 ports: - "8080:8080" ruoyi-ui: image: ${CI_REGISTRY_IMAGE}/ruoyi-ui:${DOCKER_TAG} container_name: ruoyi-test-ui ports: - "80:80" - "443:443"

部署参数里很多“为什么”，值得展开说。

数据库连接地址为什么写mysql:3306，而不是127.0.0.1:3306？因为docker compose会自动创建一个内部网络，服务之间通过服务名访问。写成服务名，依赖关系就交给网络层解析，跨主机部署时也不需要改配置。这是容器化部署的基本功。

MySQL的内存参数：innodb-buffer-pool-size=64M，这是测试环境专用的缩容配置。生产库可能有4G的buffer pool，但测试环境启动太多大配置容器会拖垮服务器。64M够跑RuoYi的测试数据量，又能显著降低内存占用。

Redis的--maxmemory 64mb同理。测试环境不需要缓存大量数据，限制内存防止本地开发机器扛不住。同时设置了--appendonly no，测试环境数据允许丢失，重启后重新加载基线数据更省事。

healthcheck为什么必须配？因为depends_on只能保证MySQL和Redis“启动”了，不能保证“就绪”。在启动早期，MySQL可能还在初始化，Redis虽然快但也有个网络监听窗口。如果不做健康检查，RuoYi后端启动时数据库连接直接失败，然后Spring Boot抛异常退出，部署看起来成功、实际起不来。加了healthcheck，再用condition: service_healthy，就能保证后端只在基础依赖就绪之后才启动。

另外还有一个参数选型的细节：RuoYi默认数据库配置文件里写的是单数据源连接信息，我在docker-compose里用SPRING_DATASOURCE_URL这样的Spring环境变量覆盖了默认配置。这种方式的好处是镜像保持不变，不同环境通过不同环境变量注入差异配置，符合“环境即代码”的原则。

3.4 环境回收与资源控制

环境创建得快，销毁也必须跟得上。否则一台服务器上慢慢积累一堆没用的容器，最后把磁盘和内存吃满。这里我提供两个层面的回收机制。

第一层，CI/CD层面的环境回收。我前面写的cleanup-environment就是这一层的实现。MR合入后手工触发清理，或者定时任务周期清理。GitLab的environment本身也有stop操作，可以在Pipeline里声明action: stop，让环境记录从“运行中”变为“已停止”，界面也会更干净。

第二层，服务器层面的定时巡检。因为CI/CD可能漏掉某些环境，比如Runner离线了、Pipeline被取消了、手工部署忘了关联分支。所以我习惯在部署服务器上放一个crontab脚本，定期扫描容器，找到超过TTL的测试环境强制销毁，并清理未使用镜像。

#!/bin/bash # 清理超过3天的测试环境容器，以及悬挂/未使用镜像 EXPIRED_HOURS=72 CURRENT_EPOCH=$(date +%s) docker ps --format '{{.Names}} {{.CreatedAt}}' | grep -E '^ruoyi-test-' | while read name created; do created_epoch=$(date -d "$created" +%s) age_hours=$(( (CURRENT_EPOCH - created_epoch) / 3600 )) if [ "$age_hours" -gt "$EXPIRED_HOURS" ]; then echo "[cleanup] 停止并删除过期容器: $name (age: ${age_hours}h)" docker rm -f "$name" || true fi done docker image prune -f

这段脚本逻辑很简单：找出名字以ruoyi-test-开头的容器，计算创建时间与当前时间的小时间隔，超过72小时就删除。最后docker image prune清理不再使用的镜像。注意一定要加|| true，防止个别容器删除失败导致脚本整体退出，影响后续清理。

资源控制方面，我会在Runner的config.toml里做一些限制。Docker executor默认可以跑任意数量的并发任务，如果不加限制，多个Pipeline同时跑，每套环境都吃资源，部署服务器很快被打爆。我通常限制并发：concurrent = 2或concurrent = 3，同时设置builds_dir和cache_dir的清理策略。也可以给每个job声明resource_group或tags，控制它们只在特定Runner上执行。

还有一点容易被忽视：镜像仓库的镜像也不断累积。每次构建都push一个新标签，几个月下来Registry体积惊人。建议在GitLab中设置镜像仓库的清理策略，保留最近N个版本，旧镜像定期删除。这不会影响测试环境，但能防止磁盘空间被CI/CD自己慢慢塞满。

4. 常见问题与排查技巧实录

无论方案设计得多完善，实际运行中总会冒出各种问题。这一节整理我在测试环境管理上遇到过的典型故障和排查经验，包括速查表和几个真实场景复盘。

4.1 典型问题速查表

我把常见问题整理成一张表，每一类都给出了排查命令和解决方向。经验不够的新手，遇到问题先对着表查，能省很多时间。

排障时的一个原则：先看容器状态，再看日志，最后看网络。很多环境问题最终都是“某一环没接上”，一个环节一个环节查，不用慌。

4.2 几次印象深刻的排障复盘

复盘几个真实案例，你大概率也会遇到。

第一个案例，回滚版本后数据库直接崩了。当时团队上线了一个新版本，测试不通过想回滚到上一个镜像。结果旧版本启动后，应用连不上数据库，因为新版本的迁移脚本改了表结构，旧代码已经不兼容新表。这个问题的根源，是测试环境数据库没有和代码版本联动。后来我把数据库迁移脚本纳入环境声明的一部分，回滚代码时同时回滚数据库schema，才避免同类问题。经验就是：环境的状态必须与代码版本强一致，容器和数据库要一起回滚，不能只回滚一个。

第二个案例，动态环境全部使用一个默认数据库名，导致数据互相污染。最初设计环境时只用容器名区分，但数据库名统一叫ruoyi_default，所有动态环境的Spring配置都连同一个库。某个分支的测试往库里写脏数据，另一个分支的测试直接失败。排查过程非常痛苦，最后才发现是数据库名冲突。修复方案就是前面代码里体现的：export MYSQL_DATABASE=ruoyi_$CI_COMMIT_REF_SLUG，让每个分支有自己的库名。这之后，数据冲突问题彻底消失。

第三个案例，RuoYi部署后前端能打开，但登录接口500。日志显示数据库连接失败，查了很久发现docker-compose里提供了环境变量，但RuoYi的应用配置文件默认优先级更高，环境变量没覆盖成功。解决办法是检查Spring配置的properties优先级，把环境变量对应的配置项显式放入application-docker.yml或调整启动参数。这个案例说明一个细节：环境变量注入依赖具体框架的配置覆盖顺序，不要假设“设置了就会生效”，要在实际日志里确认。

第四个案例，一次性最崩溃的：半夜一个定时任务触发，自动部署到测试环境，结果把正在联调的环境覆盖了，第二天早上全组炸锅。从那以后我明确规定：所有动态环境的部署，必须关联到MR或分支，禁止无标识的原生部署任务。同时环境名称必须包含分支标识，谁敢直接部署到不带标识的环境，Pipeline直接拒绝。

5. 一些真心话和建议

测试环境管理优化，不只是一堆技术操作，它更像是软件交付体系里的“地基工程”。地基不牢，上面盖的房子再好也会裂，再多的自动化、流水线优化也救不回来。

我的建议是：别想着一步到位推进“大型平台”，先从一个小团队、一条分支、一套动态环境开始。把环境定义代码化，把部署流程化，把数据治理引入基线脚本，把自动回收配上。每一步都能直接看到效果，团队的信任也会逐渐建立起来。

如果团队资源有限，只能选一件事先做，我强烈建议先做“动态环境按需创建”。这一件事能同时解决环境冲突、数据污染和部署不可控三个问题，性价比最高。做完之后再考虑更复杂的环境一致性、多环境治理。

在我自己经历过的项目里，有一句话被验证了无数次：测试环境稳定了，整个交付节奏就稳定了。CI/CD优化和测试环境管理其实是同一件事的两面，流程推进得再快，最终还是要有一个可靠的环境来承接输出。把这条链路打通，软件交付效率自然就上去了。