FLEXlm许可证管理：浮动与单机授权模式深度解析与实战配置

1. 项目概述：FLEXlm许可证管理的核心价值

在工业软件、EDA工具以及各类专业计算软件的日常使用中，我们经常会遇到一个绕不开的话题：许可证。你可能遇到过这样的场景，团队里新来了一位同事，需要安装某个关键的仿真软件，但安装后却无法启动，提示“No license available”。或者，在项目冲刺阶段，几个工程师同时需要使用同一个昂贵的分析模块，却因为授权数量不足而互相等待，严重拖慢了进度。这些问题背后，都指向一个核心的工程基础设施——软件许可证管理系统。而FLEXlm，正是这个领域里一个“古老”但生命力极其顽强的行业标准。

FLEXlm，现在更多被称为FlexNet Publisher，是Flexera公司（原Globetrotter Software）开发的一套软件许可证管理解决方案。它的核心价值在于，为软件厂商提供了一套强大、灵活且跨平台的机制，来保护其知识产权，并实现多样化的商业授权模式。对于我们这些终端用户，尤其是IT管理员、EDA支持工程师或研发团队负责人而言，深入理解FLEXlm的工作原理，绝不仅仅是为了“搞定”许可证报错。它意味着我们能更高效地规划软件资源、降低合规风险、优化采购成本，并在出现问题时快速定位根因。简单来说，掌握了FLEXlm，你就掌握了让昂贵专业软件稳定、高效服务于团队生产力的钥匙。

本文将从一线工程师的视角，深入拆解FLEXlm的两种核心授权模式——浮动授权与单机授权。我不会仅仅停留在概念介绍，而是会结合多年在芯片设计、结构仿真等环境中的实战经验，详细讲解其底层原理、配置细节、监控方法，以及那些手册上不会写的“踩坑”实录。无论你是初次接触许可证管理的新手，还是希望优化现有环境的老手，都能从中找到可直接落地的解决方案。

2. 核心原理：License Server与Client的通信架构

要理解FLEXlm，首先必须吃透其最基础的C/S（客户端/服务器）架构。这个架构清晰地划分了权限控制的边界，是整个系统运行的基石。

2.1 核心组件角色解析

一个典型的FLEXlm环境包含三个关键角色，它们各司其职，共同完成许可证的校验与发放。

1. License Server（许可证服务器）这是整个系统的“大脑”和“金库”。它是一台（或多台）专门运行FLEXlm守护进程（lmgrd及其供应商守护进程，如metrowks.exe）的计算机。服务器上存放着核心的许可证文件（license.dat），这个文件由软件厂商根据你购买的授权信息生成，是合法的“授权凭证”。服务器的核心职责包括：

  • 守护进程管理：lmgrd是总管家，负责启动、监控和停止各个软件厂商特定的供应商守护进程（Vendor Daemon）。
  • 授权验证与分发：当客户端申请许可证时，供应商守护进程会读取license.dat，验证请求的合法性（如功能名称、数量、有效期、主机ID等），并在授权池中标记相应的席位为“已使用”。
  • 状态维护：实时跟踪所有已借出许可证的状态，包括哪个用户、从哪个主机、使用了哪个功能、何时开始等。

2. License Client（许可证客户端）这就是我们日常运行专业软件（如Cadence Virtuoso, Synopsys VCS, Ansys Mechanical等）的工程师工作站。当启动这些软件时，软件内嵌的FLEXlm客户端库（通常是lmgr*.dll或对应的Unix共享库）会被调用。客户端的职责很单纯：

  • 发起请求：向预先配置好的License Server地址和端口，发送一个包含所需功能（Feature）名称的授权请求。
  • 处理响应：接收服务器的响应。如果成功，则获取一个“许可令牌”，软件正常启动；如果失败（如无可用席位、授权过期等），则向用户抛出错误信息。

3. License File（许可证文件）这是一个文本文件（通常命名为license.dat），是连接厂商授权和实际服务器的桥梁。它的内容包含了加密的授权信息，格式大致如下：

SERVER my_server_hostname 001122334455 27000 VENDOR metrowks port=27001 FEATURE Simulation_Suite metrowks 2025.1231 10 \ SIGN2=”ABCD...EFGH” HOSTID=001122334455
  • SERVER行：定义了许可证服务器的主机名、网卡MAC地址（HOSTID）和lmgrd监听的端口（通常为27000）。
  • VENDOR行：定义了供应商守护进程的名称和其监听的端口。
  • FEATURE行：定义了具体的授权功能、供应商、过期日期、可用数量以及加密签名。

注意：license.dat文件中的HOSTID必须与运行License Server的物理机器的网卡MAC地址严格一致。很多初始化失败的问题都源于此。对于服务器有多个网卡的情况，需要明确指定使用哪一个。

2.2 通信协议与端口机制

FLEXlm主要使用TCP/IP协议进行通信，但也部分依赖UDP进行广播发现。端口管理是其配置中的一个关键点。

  • lmgrd端口（默认27000）：这是客户端首先连接的端口。lmgrd作为一个调度器，接收客户端请求，并将其转发给对应的供应商守护进程。
  • 供应商守护进程端口（如27001, 27002...）：每个软件厂商的守护进程监听独立的端口。端口号在license.dat的VENDOR行中定义。
  • UDP广播（默认3000-3002）：客户端可以配置为向网络广播寻找许可证服务器。这在小型、简单的环境中可能有用，但在大型企业网络或防火墙严格限制的环境中，通常建议直接指定服务器主机名和端口，以避免广播包被过滤带来的问题。

为什么是C/S架构？这种架构的优势非常明显：集中管理。管理员只需要在服务器端更新一次许可证文件，所有客户端即刻生效。它能实现浮动授权的共享，精确控制并发用户数，防止超量使用。同时，所有授权检查日志都集中在服务器，便于审计和排查问题。相比之下，早期的单机软加密狗或纯文件验证的方式，在部署、升级和监控方面要笨拙得多。

3. 授权模式深度剖析：浮动 vs. 单机

理解了基础架构，我们来看FLEXlm如何通过两种主要模式来满足不同的业务场景。这是决定软件采购成本和团队使用模式的关键。

3.1 浮动授权：资源共享的智慧

浮动授权，有时也称为并发授权或网络授权，是工程团队中最常见、最高效的授权模式。它的核心思想是：购买一定数量的软件使用权（席位），形成一个“授权池”，所有合规的客户端都可以从这个池子里借用，用完即还。

工作原理： 假设公司购买了10个席位“Feature_A”的浮动授权。这10个授权席位存在于License Server的池中。

  1. 工程师甲在工作站A上启动需要“Feature_A”的软件，客户端向服务器发起请求。
  2. 服务器检查池中是否有可用席位。有，则分配一个给甲，池中可用席位变为9个，并记录“甲@工作站A占用1席”。
  3. 工程师乙在工作站B上同样启动软件，服务器再分配一席，可用席位变为8个。
  4. 当甲关闭软件时，客户端会向服务器发送释放信号（或服务器通过心跳机制检测到连接断开），该席位被回收到池中，可用席位恢复为9个。
  5. 如果此时第11位工程师尝试启动软件，服务器会拒绝请求，返回“No license available”错误。

应用场景与优势：

  • 团队协作：非常适合一个团队需要间歇性、非同时使用同一昂贵软件的场景。例如，一个20人��设计团队，可能高峰时段同时工作的只有8-10人，购买10个浮动授权就能满足需求，远比购买20个单机授权经济。
  • 成本优化：最大化授权利用率，避免了授权因绑定到闲置机器而造成的浪费。
  • 灵活管理：管理员可以轻松地在服务器端监控所有授权的实时使用情况，了解软件的使用频率和高峰时段，为后续采购提供数据支持。

实操心得：如何确定浮动授权的数量？这是一个经典的规划问题。盲目购买会造成浪费，购买不足则影响工作。我的经验是：

  1. 历史数据分析：如果已有旧系统，利用FLEXlm的日志或监控工具（如lmstat）分析过去3-6个月的高峰并发用户数。通常，以“第95百分位数”的并发数作为基准，再增加10-20%的缓冲，是一个稳健的策略。
  2. 用户访谈与工作流分析：了解团队的工作模式。是大家固定时间一起跑仿真？还是时间错开？某些“杀手级”功能可能只有少数人需要。
  3. 考虑“借用”功能：FLEXlm支持许可证借用，允许用户将浮动授权临时“借”到笔记本电脑上离线使用（通常有期限，如7天）。这会影响可用池大小，规划时需要预留这部分余量。

3.2 单机授权：专属绑定的保障

单机授权，也称为节点锁定授权，是另一种基础模式。它将软件授权永久地绑定到一台特定的计算机（通过其HOSTID，通常是主网卡的MAC地址）。

工作原理： 在license.dat文件中，单机授权的FEATURE行会包含HOSTID=参数，且授权数量通常为1（或为0，表示无限期，但已绑定）。

FEATURE Premium_Tool metrowks 1.000 permanent 1 \ SIGN2=”XXXX...” HOSTID=001122334455

这个授权只能被HOSTID为001122334455的机器使用。即使这台机器没有连接网络，只要本地能正确指向许可证文件（甚至文件就在本地），软件就能启动。其他任何机器都无法使用这个授权。

应用场景与优势：

  • 固定工作站：用于某些需要7x24小时运行的关键任务机器，如作为数据服务器、持续集成节点或专用渲染农场中的节点。
  • 高安全环境：在物理隔离或网络策略极其严格的网络中，无法部署License Server时，单机授权是唯一选择。
  • 离线作业：对于需要长期在无网络环境（如野外、保密实验室）下工作的设备。
  • 简化部署：对于极小规模或个人用户，省去了搭建和维护License Server的复杂度。

注意事项：单机授权的“不灵活性”单机授权的最大缺点就是缺乏弹性。如果这台绑定的机器硬件故障、需要升级或淘汰，授权转移会是一个行政和技术上的流程。通常需要联系软件供应商，提供新旧机器的HOSTID，申请重新生成许可证文件。这个过程可能需要时间，会造成服务中断。因此，对于团队核心生产力工具，除非必要，否则更推荐浮动授权。

3.3 混合模式与高级特性

在实际的企业环境中，纯粹的单一模式很少见，更多的是混合部署：

  • 混合授权池：一个license.dat文件里可以同时包含浮动授权和绑定到不同服务器的单机授权。lmgrd能够统一管理。
  • 许可证借用：这是浮动授权的一个超实用扩展。用户可以使用lmborrow命令，从浮动池中借出一个授权，在指定天数内离线使用。这对于需要出差或在家工作的工程师来说至关重要。借用后，服务器端的可用席位会相应减少，直到借用过期或被手动归还。
  • 分组与排队：一些高级的FLEXlm配置支持将用户分组，并为不同的组分配不同的优先级或授权池。甚至可以实现排队功能，当所有授权被占用时，后续请求可以排队等待，而不是直接拒绝。

4. 实战配置：从零搭建FLEXlm许可证服务器

理论说得再多，不如动手配一遍。这里我将以在Linux服务器上部署一个典型的FLEXlm环境为例，展示完整流程。Windows服务器的步骤类似，主要是执行文件和工具界面的区别。

4.1 环境准备与文件获取

假设我们有一台主机名为lic-server的CentOS 7服务器，我们需要为“MetroWorks”套件（假设的EDA软件）部署许可证服务。

  1. 获取安装包：从软件供应商处获取FLEXlm服务器安装包。这通常包含以下文件：

    • lmgrd：许可证管理器守护进程。
    • lmutil：一个多功能命令行工具，包含lmstat,lmdiag,lmremove等功能。
    • vendor daemon：供应商守护进程，例如metrowks(实际名称因厂商而异)。
    • license.dat：你的许可证文件。这是最重要的文件，务必妥善保管。

  2. 检查系统依赖：确保服务器已安装基本的32位兼容库（因为很多老版本的FLEXlm组件是32位的）。

    # 对于RHEL/CentOS sudo yum install glibc.i686 libgcc.i686 # 对于Ubuntu/Debian sudo apt-get install libc6:i386 libstdc++6:i386

  3. 规划目录结构：建议创建一个清晰的目录来管理所有文件，避免混乱。

    sudo mkdir -p /opt/flexlm sudo chown -R `whoami`:`whoami` /opt/flexlm # 假设用当前用户运行 cd /opt/flexlm

    将获取到的lmgrd,lmutil,metrowks等文件拷贝到此目录。将license.dat也放在这里或/opt/flexlm/licenses/下。

4.2 许可证文件定制与校验

拿到供应商发来的license.dat后，不要直接使用，必须先进行核对和必要的修改。

  1. 修改SERVER行：用文本编辑器打开license.dat。找到以SERVER开头的行。将其中的主机名和HOSTID修改为你实际服务器的信息。

    # 查看服务器主机名 hostname # 查看服务器主要网卡的MAC地址 (HOSTID) ip addr show | grep ether | head -n1 | awk '{print $2}' | tr -d ':'

    假设主机名是lic-server，MAC地址是00:11:22:33:44:55。那么将SERVER行改为：

    SERVER lic-server 001122334455 27000

    注意：HOSTID必须是连续12位十六进制数字，去掉冒号。

  2. 检查VENDOR行和端口：确认VENDOR行定义的守护进程名称和端口号。确保这些端口（如27000, 27001）在服务器的防火墙上已开放。

    sudo firewall-cmd --permanent --add-port=27000/tcp sudo firewall-cmd --permanent --add-port=27001/tcp sudo firewall-cmd --reload # 或者直接暂时关闭防火墙进行测试（不推荐生产环境） # sudo systemctl stop firewalld

  3. 校验文件语法：使用lmutil进行快速校验。

    cd /opt/flexlm ./lmutil lmcksum -c license.dat

    如果文件没有明显错误，此命令通常会静默退出或显示校验和。如果报错（如“Invalid license file syntax”），则需要仔细检查每一行的格式，特别是反斜杠\续行符前后不能有空格。

4.3 启动服务与开机自启

配置完成后，我们可以手动启动服务进行测试。

  1. 手动启动：

    cd /opt/flexlm # 启动lmgrd，指定许可证文件路径和日志文件 ./lmgrd -c license.dat -l /var/log/debug.log
    • -c：指定许可证文件路径。
    • -l：指定调试日志输出��件。生产环境务必开启日志，它是排查问题的第一手资料。

  2. 验证服务状态：

    ./lmutil lmstat -a -c license.dat

    这个命令会显示服务器状态、所有供应商守护进程的状态以及当前已使用的许可证特征列表。如果��到你的metrowks守护进程状态为“UP”，并且列出了可用的FEATURE，那么恭喜你，服务器端基本配置成功。

  3. 配置系统服务（Systemd）以实现开机自启： 手动启动不适合生产环境。我们需要创建一个systemd服务单元文件。

    sudo vim /etc/systemd/system/flexlm.service

    写入以下内容（根据你的实际路径调整）：

    [Unit] Description=FLEXlm License Server After=network.target [Service] Type=forking User=your_username # 改为运行服务的实际用户 Group=your_group WorkingDirectory=/opt/flexlm ExecStart=/opt/flexlm/lmgrd -c /opt/flexlm/license.dat -l /var/log/flexlm.log ExecStop=/opt/flexlm/lmutil lmdown -c /opt/flexlm/license.dat -all Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target

    然后启用并启动服务：

    sudo systemctl daemon-reload sudo systemctl enable flexlm.service sudo systemctl start flexlm.service sudo systemctl status flexlm.service # 检查运行状态

4.4 客户端配置

服务器就绪后，需要在工程师的工作站（客户端）上配置软件，使其指向我们的许可证服务器。

方法一：环境变量（最通用）在用户的shell配置文件（如~/.bashrc或~/.cshrc）中设置：

# 对于bash export LM_LICENSE_FILE=27000@lic-server # 或者使用端口@主机名 的格式 # 如果有多个服务器，可以用分号隔开 # export LM_LICENSE_FILE=27000@server1;28000@server2
# 对于csh/tcsh setenv LM_LICENSE_FILE 27000@lic-server

方法二：软件特定配置文件许多软件允许在其安装目录或用户目录下创建特定的许可证配置文件。例如，一些软件会查找一个名为license.lic或.lic的文件，其内容就是27000@lic-server。

方法三：使用供应商提供的工具像Cadence、Synopsys等都有自己的配置工具，通常提供一个图形界面让你输入许可证服务器地址。

实操心得：LM_LICENSE_FILEvs.[VENDOR]_LICENSE_FILE有些软件会优先检查特定于供应商的环境变量，如CDS_LIC_FILE(Cadence),SNPSLMD_LICENSE_FILE(Synopsys)。如果设置了这些变量，它们会覆盖LM_LICENSE_FILE。为了避免混淆，在团队中建议统一使用LM_LICENSE_FILE，并在服务器端确保所有需要的供应商守护进程都已启动。可以在客户端用lmutil lmdiag命令来测试连接：

lmutil lmdiag -c 27000@lic-server -f Feature_Name

这个命令会模拟请求指定Feature，并显示详细的诊断信息，是测试连通性的利器。

5. 监控、维护与故障排查实录

许可证服务器上线后，日常监控和故障处理是保障稳定的关键。下面分享一些实战中积累的工具和技巧。

5.1 日常监控命令

掌握几个核心的lmutil命令，就能对服务器状态了如指掌。

  1. 查看服务器和守护进程状态：

    lmutil lmstat -a -c 27000@lic-server

    这是最常用的命令，输出示例：

    License server status: 27000@lic-server License file(s) on lic-server: /opt/flexlm/license.dat: lmgrd is running: UP Vendor daemon status (on lic-server): metrowks: UP Feature usage info: Users of Feature_A: (Total of 10 licenses issued; Total of 3 licenses in use) "Feature_A" v1.0, vendor: metrowks floating license user1 host1 (v1.0) (lic-server/27001 1001), start Tue 4/1 10:00 user2 host2 (v1.0) (lic-server/27001 1002), start Tue 4/1 10:05 user3 host3 (v1.0) (lic-server/27001 1003), start Tue 4/1 09:55

    一目了然：服务器和守护进程是否运行，每个授权功能的总数和已使用数，以及谁在用、从哪台机器、何时开始的。

  2. 查看详细的许可证文件内容：

    lmutil lmstat -c license.dat -i

    这会解析license.dat文件，列出所有FEATURE的详细信息，包括名称、版本、数量、过期日期、主机限制等。在核对授权信息时非常有用。

  3. 强制移除占用： 有时用户异常退出（如电脑崩溃），许可证没有被正常释放，导致席位被“僵尸”占用。可以使用lmremove强制释放。

    # 首先查看占用句柄的详细信息 lmutil lmstat -a -c 27000@lic-server # 找到需要移除的句柄ID（例如上面的1001） lmutil lmremove -c 27000@lic-server metrowks Feature_A 1001

    警告：此操作会强制关闭该用户的软件许可，可能导致其工作丢失。操作前务必与用户沟通确认。

5.2 常见故障排查流程

当客户端报错“Cannot connect to license server”或“No license available”时，可以按照以下流程层层排查。

第一步：客户端本地检查

  1. 检查环境变量：echo $LM_LICENSE_FILE，确认指向正确的服务器和端口。
  2. 测试网络连通性：ping lic-server，确认能解析主机名并通。
  3. 测试端口连通性：telnet lic-server 27000或nc -zv lic-server 27000。如果连接失败，问题可能出在网络上或服务器端。

第二步：服务器端检查

  1. 检查服务进程：ps aux | grep lmgrd，确认lmgrd和供应商守护进程（如metrowks）都在运行。
  2. 检查日志文件：tail -f /var/log/debug.log。FLEXlm的日志非常详细，任何错误（如无效的HOSTID、许可证过期、端口冲突）都会在这里打印。这是排查问题的黄金位置。常见的错误信息有：
    • Cannot find SERVER line in license file：许可证文件路径错误或SERVER行格式不对。
    • Invalid host.：许可证文件中的HOSTID与服务器实际MAC地址不匹配。
    • License server system does not support this feature.：供应商守护进程未启动或版本不匹配。
    • No such feature exists.：客户端请求的功能名在许可证文件中不存在（注意大小写敏感）。
  3. 检查端口占用：netstat -tlnp | grep :27000，确认lmgrd在监听指定端口。如果端口被其他进程占用，需要停止该进程或修改license.dat中的端口号。

第三步：深入诊断如果以上都正常，但问题依旧，可以使用lmdiag进行端到端诊断。

lmutil lmdiag -c 27000@lic-server -f Feature_A

这个命令会模拟一个客户端请求的全过程，并报告每一步的成功与失败，能精确定位到是网络问题、服务器配置问题还是许可证文件本身的问题。

5.3 维护要点与经验技巧

  1. 日志轮转：FLEXlm的日志文件如果不加管理会无限增长。可以使用Linux自带的logrotate工具定期轮转和清理旧日志。
  2. 许可证文件备份：license.dat文件是命根子。每次更新（如新增授权、续期）后，务必进行备份。建议将其纳入配置管理（如Git）。
  3. 时间同步：许可证服务器和所有客户端之间的系统时间差不能太大（通常建议在几分钟内）。如果服务器时间远快于客户端，客户端可能会认为许可证已过期；反之亦然。建议部署NTP服务确保所有机器时间同步。
  4. 防火墙策略：除了开放lmgrd和供应商守护进程的TCP端口，有时还需要开放用于发现的UDP端口（默认3000-3002）。但在严格管控的网络中，更推荐禁用广播发现，强制使用静态服务器地址配置。
  5. 处理“僵尸”许可证：除了使用lmremove，还可以在启动lmgrd时使用-t参数设置超时时间（如-t 7200表示2小时无心跳则释放授权），或定期重启服务来清理。但重启会影响所有用户，需在维护窗口进行。

6. 进阶话题与最佳实践

在掌握了基础运维后，一些��阶配置可以进一步提升系统的可靠性和效率。

6.1 冗余与高可用配置

对于关键生产环境，单点许可证服务器是巨大的风险。FLEXlm支持三服务器冗余模式，提供高可用性。

原理：配置三台许可证服务器，使用相同的license.dat文件（但SERVER行需列出所有三台服务器）。三台服务器通过内部协议进行选举和状态同步。客户端只需指向其中任意一台，如果该台宕机，客户端会自动尝试列表中的下一台。

配置示例： 在license.dat文件中：

SERVER server1 00:11:22:33:44:55 27000 SERVER server2 aa:bb:cc:dd:ee:ff 27000 SERVER server3 11:22:33:44:55:66 27000 VENDOR metrowks port=27001 FEATURE MyTool metrowks 2025.1231 10 SIGN=...

客户端环境变量设置为：export LM_LICENSE_FILE=27000@server1,27000@server2,27000@server3

注意事项：

  • 三台服务器的系统时间必须高度同步。
  • 网络延迟必须很低且稳定。
  • 许可证文件必须完全一致，且定期在所有服务器上同步更新。
  • 这种模式增加了管理复杂度，但对于要求7x24可用的核心环境是值得的。

6.2 性能监控与容量规划

仅仅知道“有没有许可证在用”是不够的，我们还需要知道“用得怎么样”。

  1. 使用率统计：定期（如每天）运行lmstat命令，将输出重定向到文件，然后编写脚本解析日志，统计每个FEATURE的日均/月均并发使用数、峰值使用数、使用时段分布。这些数据是申请预算、调整授权数量的最强有力依据。
  2. 用户行为分析：通过日志，可以分析哪些用户、哪些项目占用了最多的授权资源。这有助于进行内部成本分摊或优化工作流程。
  3. 工具集成：可以考虑使用开源的监控工具（如Prometheus）搭配lmutil输出自定义指标，或使用商业的许可证管理平台（如Flexera的FlexNet Manager），它们能提供更直观的仪表盘和报告。

6.3 安全考量

许可证服务器本身也可能成为安全风险点。

  1. 最小权限原则：运行lmgrd的用户应是一个专用的、低权限的系统用户，而不是root。
  2. 文件权限：确保license.dat文件仅对运行服务的用户可读，避免泄露授权信息。
  3. 网络隔离：将许可证服务器部署在内部受信任的网络区域，只对必要的客户端子网开放所需端口。避免将其暴露在公网。
  4. 定期审计：检查日志中是否有异常的连接尝试或大量的授权失败记录。

回顾整个FLEXlm的配置和管理过程，其核心思想在于集中控制和精细化管理。从最初的手动启动服务、反复调试license.dat文件，到后来编写自动化部署脚本、搭建冗余集群、构建监控仪表盘，我最大的体会是：把许可证管理当成一个严肃的基础服务来对待。它看似不起眼，但一旦出问题，影响的是整个团队的研发进度。养成定期检查日志、分析使用报告、与软件供应商保持沟通的习惯，能提前规避掉90%的紧急故障。最后一个小技巧，对于复杂的多软件、多版本环境，为每个主要的软件套件建立独立的文档，记录其特定的供应商守护进程名称、端口、环境变量要求以及已知的兼容性问题，这份“知识库”在新人入职或环境迁移时能节省大量时间。