温室环境控制软件是农业数字化转型当中比较容易被低估的一类系统。相比电商、金融、工业互联网这些热门赛道的测试项目温室环控软件的测试人群并不大网上能查到的实战经验也很零散。但如果真正深入做过独立测试你会发现这类软件的业务复杂度一点都不低既要管温、光、水、气、肥又要联动风机、湿帘、天窗、内外遮阳、灌溉阀门、环流风机等一大堆现场设备还得应对暴雨、寒潮、夏季高温这些极端天气。今天我想借一篇“花卉温室环境控制软件测试”的实战复盘把这类项目究竟难在哪、测试策略怎么搭、现场验证怎么做一次讲清楚。这篇内容适合两类人读一类是正在做或准备做农业物联网、智能温室、设施农业相关软件测试的工程师另一类是负责智慧农业项目交付的项目经理或测试负责人需要在资源有限的情况下把功能、性能、可靠性、算法效果都测到位。文章不会堆测试八股而是围绕真实项目中反复出现的核心挑战展开每一步都按“为什么这么设计、落地时要注意什么”来讲。1. 花卉温室环控软件测试的前提先搞清被测对象到底是什么1.1 环控软件不是普通业务系统它是一套实时决策系统做测试的第一步不是写用例而是先理解被测系统的本质。花卉温室环境控制软件和常见的后台管理系统有个非常大的区别它不只是“记录数据”和“展示报表”的信息系统而是一套需要实时采集环境数据、根据设定目标值自动决策、再输出控制指令的闭环系统。以蝴蝶兰催花温室为例环控软件要同时管理六个维度的环境因子温度、湿度、光照、二氧化碳浓度、基质含水量、EC值营养液电导率。每一路因子背后都有对应的执行机构温度对应风机、湿帘、保温被、热风机光照对应内遮阳、外遮阳、补光灯水分对应滴灌电磁阀、喷雾系统。软件的核心逻辑可以简单概括为“采集—决策—控制—反馈”四个环节不断循环。测试人员如果不把这条决策链路拆清楚很容易陷入“只测页面、不测逻辑”的误区。我在第一次参与这类项目时花了两周时间梳理系统架构画出数据流向图才真正理解为什么一个看似简单的“开风机”动作会牵涉到传感器数据有效性判断、滞后延时补偿、优先级仲裁、设备保护互锁等多层逻辑。1.2 测试类型的侧重点和普通软件完全不同同样叫软件测试环控软件在测试类型上的权重分配和互联网软件差异很大。功能测试当然要做但它不是最难的真正决定项目质量的是可靠性测试、异常场景测试、时序逻辑测试和现场联合调试。功能测试占比大约30%重点验证控制模式切换、参数配置、报警功能、历史数据查询。可靠性测试占比30%左右重点验证软件长期运行是否稳定、会不会死机、看门狗机制是否生效。异常场景测试占比20%重点验证传感器故障、通信中断、设备拒动等异常情况下的软件表现。现场联合调试占比20%这部分不是纯软件验证而是软件硬件网络环境的系统级验证。这个比重和银行软件测试、电商平台测试有很大差异。银行软件最怕资金对不上账电商软件最怕并发扛不住而环控软件最怕的是环境已经偏离设定范围了软件还认为一切正常。这种“静默失效”是温室控制领域最危险的故障模式也是测试设计中必须重点覆盖的场景。1.3 明确验收标准是后续所有工作的基础项目开始阶段务必要和需求方确认一套可量化的验收标准。例如温度控制精度要求“目标温度上下1.5摄氏度以内”那么测试就要围绕这个精度设计工况如果要求“断电恢复后在10分钟内恢复自动控制”那测试就要专门做断电重启验证。实际操作中很多项目做不到这么明确的验收指标。甲方常常只会说“要能自动控制温度”具体允许的波动范围、响应时间、故障恢复要求都不说。这时候测试负责人不能等需要根据温室种植作物的生长需求主动提出建议值。花卉类温室一般比蔬菜温室要求更高例如红掌、蝴蝶兰等高档盆花对温度波动非常敏感昼夜温差控制不好直接影响花芽分化和上市品质建议把控制精度定位在正负1摄氏度到正负1.5摄氏度的区间湿度控制精度定位在正负5%到正负8%的区间。2. 六大核心挑战逐个拆解为什么温室环控软件这么难测2.1 挑战一环境系统的空间差异性和时间滞后性温室环境控制有一个所有做物联网的人都清楚的痛点环境参数在空间上是不均匀的。实际温室里靠近风机端的温度和靠近湿帘端的温度能差出3到5摄氏度同一排种植架上上层光照和下层光照可能差一倍。软件界面上的“当前温度25.3摄氏度”很可能只是一个传感器的读数根本代表不了整个温室的平均状态。时间维度的滞后更为棘手。风机启动后温室内温度并不会立刻下降往往需要5到15分钟才能看到趋势变化灌溉阀门打开后基质水分要达到稳定也需要数小时。这种大滞后特性意味着软件看到的反馈数据是过去时刻的系统状态如果控制算法的预测和补偿做得不好就很容易出现振荡——温度高了开风机温度降下来了关风机但关掉后温度继续下降过一会儿又触发加温整个系统像弹钢琴一样来回跳。测试这类系统不能只在测试环境里做瞬时验证必须设计带有时间跨度的连续测试用例。例如验证温度控制功能时要连续记录至少2个小时的温度曲线观察控制是否收敛、有没有持续振荡、有没有极限环。我在实际项目中专门统计过在未做算法优化的情况下大约有60%的新接入温室会出现温度振荡现象振荡周期在15到30分钟之间反复修正参数后仍需要一到两周时间才能稳定。2.2 挑战二传感器数据可靠性是测试中的隐形炸弹环控软件的所有决策都建立在传感器数据之上。传感器一旦给出错误数据软件决策就必然错误而且可能是持续性的错误。温室常见的传感器故障包括探头被水雾覆盖导致湿度读数虚高、热辐射导致温度读数偏高、传感器漂移导致数值缓慢偏离真实值、线路接触不良导致间歇性失真、通信模块故障导致数据长时间不更新。这些故障在实验室里很难提前发现因为实验室的传感器都是精心布置、工作正常的。但一进入温室现场高温高湿高腐蚀的环境会立刻把传感器弱点放大。测试中必须建立一套传感器可信度验证方案通过人工巡检采集的实测数据与软件显示数据做对比偏差超出阈值就启动全面排查。我常建议测试团队采用“三条数据线”的验证思路第一条是温室内的参考级温湿度记录仪数据第二条是控制系统中使用的传感器数据第三条是软件界面显示的数据。三个数据源两两对比既能查出传感器硬件问题也能查出软件的数据处理逻辑问题。2.3 挑战三硬件设备联动和I/O控制的时序复杂性温室环控软件最终要通过继电器、接触器、变频器等硬件去控制设备。多个设备同时动作时时序是一个极其关键的问题。比如夏季降温策略中软件可能需要同时打开湿帘水泵、启动风机、关闭迎风面天窗。如果执行顺序不对先开湿帘再关天窗可能会让热空气短时间大量涌入温室如果湿帘水泵打开了但风机没启动湿帘区域的湿度会过高还可能让水汽凝结在作物叶面。更麻烦的是设备之间的互锁逻辑。热风机和湿帘在逻辑上是对抗设备不可能同时开启遮阳幕布和补光灯在光照策略上需要联动遮阳拉合时补光灯的状态要重新判断灌溉阀门和液位开关之间有保护联动水箱水位过低时不能启动灌溉泵。这些互锁关系如果只靠人工点检效率极低且容易遗漏。测试设计上我的做法是建一张“设备动作真值表”把温室里的所有执行设备列成表头逐对检查每个设备组合是否允许同时动作标注出哪些组合是硬件限制禁止的哪些是逻辑上不允许的哪些是允许但需要延时的。然后用自动化脚本遍历所有设备组合验证软件的实际输出是否符合真值表要求。这个方法听起来简单但能把互锁逻辑的覆盖度做到接近100%。2.4 挑战四控制算法的可靠性验证缺少现成方法环控软件的核心竞争力在于控制算法。同样是降温简单模式是“温度高过阈值就开风机”高级模式会根据温湿度综合计算焓值、根据天气预报预判降温趋势、根据作物品种调整控制策略。算法复杂度上去了验证难度也成倍增加。算法验证最难的地方在于缺少标准答案。普通软件功能测试可以用预期的输入输出对照但控制算法的输出是连续的、多变量耦合的没有一个简单公式可以算出“正确”的控制指令。就算让行业专家现场点评也只能凭经验说“这个控制策略合理”很难给出量化标准。我对算法验证采用“三位一体”的思路第一步用仿真环境跑回归测试把历史环境数据灌入测试系统对比算法优化前后的控制输出差异第二步做硬件在环测试用模拟量发生器代替真实传感器测试软件在各种输入组合下的响应是否符合设计意图第三步做现场长时间运行观测重点看目标值的超调量、稳定时间、振荡次数三个指标。这套方法让我在项目验收时底气足了很多至少每个控制策略的优劣都有数据支撑而不是“凭感觉还行”。2.5 挑战五跨平台兼容与远程升级的测试盲区温室环控系统的组成通常比较杂。控制器可能来自不同厂商通信协议有Modbus RTU、Modbus TCP、DL/T645也有私有协议上位机软件有的跑在Windows工控机上有的跑在Linux边缘网关里用户访问端又有Web平台、手机App、触摸屏HMI三种形态。测试资源有限时跨平台兼容性测试往往最先被砍掉但它恰恰是现场返工率最高的环节。特别是远程升级功能看起来简单做起来坑非常多。升级过程中断网怎么办升级包损坏怎么办升级失败后设备还能不能回滚到旧版本升级期间正在进行的自动控制任务要不要暂停这些异常场景如果在测试阶段没有充分覆盖到现场出现一次升级故障造成的损失可能是一个大棚的作物。我在测试中会专门构建一个“弱网实验室”——用网络损伤仪模拟丢包、延迟、抖动验证远程升级在不同网络质量下的表现同时设计断电注入测试在升级包传输到一半时切断电源验证设备重新上电后能否从异常状态恢复正常。这类测试虽然枯燥但价值极高能直接把远程维护的故障率降一个数量级。2.6 挑战六测试数据缺乏、气象场景不可控温室环控软件最依赖的两类外部数据是气象数据和作物数据。气象数据不准确控制策略就会基于错误前提做决策作物数据缺失很多生长模型就无从验证。但测试阶段恰恰很难拿到真实完整的气象数据——过去十年的逐分钟气象记录在很多园区根本不存在就算有也分散在多个系统里格式不统一质量参差不齐。既然真实数据拿不到测试就要靠构造可靠的测试数据来弥补。我会把气象数据构造分成三类场景常态场景依据当地气象站的月平均值构造、极端场景依据历史上的寒潮、高温、连续阴雨数据构造、边界场景数据在阈值边界附近抖动测试控制的触发和恢复边界。极端场景的测试数据尤其重要因为温室环控系统平时很安逸真正出问题往往就在极端天气来临时。3. 分层测试策略与仿真验证体系类似沙盘推演式的测试打法3.1 用模型仿真构建可重复的测试环境温室环控测试最大的痛点是环境不可控——你不可能为了让软件“觉得热”就把温室真加热到38摄氏度更不可能为了测试加温逻辑在夏天把温室设备全部关掉等温度自然下降。应对这个问题的标准做法是构建环境仿真模型把物理环境“搬到”测试机里。常见的仿真方案是建立一个温室内环境变化模型输入是外部气象数据和控制设备状态输出是温室内温度、湿度、光照等参数的预测值。软件在仿真模式下,不再读取真实传感器而是读取仿真模型算出的环境参数控制指令也不发给真实设备而是返回给仿真模型作为下一步计算的输入。这样测试人员就可以通过调节仿真模型的输入参数比如让外部温度缓慢上升、让湿度突然跳变自由地构造出各类环境场景。仿真测试最大的价值是场景可重复性。真实温室里测一次降温逻辑可能需要等天气仿真环境下10分钟就能模拟出“从早上8点到下午4点的持续升温”而且同一个场景可以反复跑一百遍保证每次测试的初始条件完全一致。这对问题复现和修复验证太重要了我在现场测试时花三天才能复现的问题回到实验室用仿真数据半天就能定位根因。3.2 硬件在环测试把传感器和执行器的“戏”做足单纯的软件仿真只能验证控制逻辑还验证不了软硬件的接口。于是要在仿真环境上增加“硬件在环”这一层核心思路就是用可编程信号发生器模拟传感器输出用数字量输入模块采集软件的控制输出形成一套闭环。硬件在环测试的具体做法是把温湿度传感器探头替换成信号发生器发生器按照预设曲线输出对应的电阻值或电流信号把风机、湿帘等执行设备的动力线断开改接到信号采集板上由采集板记录继电器闭合状态和持续时间。这样一来软件以为自己在控制真实的温室设备但实际上整个物理层已经被测试工具接管了。实际测试中发现很多问题只有在这一层才会暴露。例如某次我们模拟温度持续超过上限软件正确发出了“开风机”指令但由于继电器频繁吸合导致触点温度过高接触器出现热保护脱扣——这种问题在纯软件测试中永远不会出现而到了硬件在环层就能及时发现。所以硬件在环测试既是软件测试的延伸也是硬件可靠性验证的重要手段。3.3 分层测试在不同阶段的资源分配策略项目时间有限不能每个阶段都平均用力。我个人的经验是“仿真测试占40%、硬件在环测试占30%、现场联合测试占30%”。前两个阶段尽量多花时间因为越早发现问题修复成本越低现场测试时间压缩得再紧只要前两层的质量做扎实现场问题数量就会显著下降。第一阶段研发期以模型仿真为主功能测试、算法验证、异常场景全覆盖力争在软件交付前解决70%以上缺陷。第二阶段集成期以硬件在环为主接口测试、时序测试、设备联动测试、通信稳定性测试集中执行。第三阶段试运行期以现场联合测试为主重点验证长期运行稳定性、极端天气应对能力和远程维护能力。这里要特别提醒一点不要因为觉得仿真环境“不真实”就轻视它的结果。恰恰相反仿真环境排除掉了现场环境的各种干扰因素缺陷一旦暴露出来根因往往非常干净清晰。真正难处理的现场问题反而是那些在仿真环境下一切正常、一到现场就开始抽风的问题——这类问题通常是环境因素和设备物理特性耦合导致的需要单独的方法论来对付。4. 核心环节实操记录从测试设计到现场执行的完整路径4.1 测试用例设计从“功能点驱动”升级为“场景驱动”传统测试用例设计习惯于按功能点拆分——“温度设置页面的边界值测试”“报警记录的翻页测试”。但在温室环控软件中这种设计方式会遗漏大量跨功能交互的缺陷。我在项目里采用“场景驱动”的设计方法把整个测试生命周期划分为几个核心场景族日常自动控制场景、极端天气应对场景、设备维护检修场景、断电恢复场景、报警联动场景、用户误操作场景。每个场景族内部再细化成具体场景比如“极端天气应对场景”可以拆成夏季午后突然雷暴温度骤降、湿度骤升时控制策略的切换。冬季夜间停电后室温持续下降来电后恢复策略是否把加温设备按正确顺序启动。连续阴雨天后突然放晴光照强度瞬间升高遮阳系统能否快速响应。场景设计的核心准则是不要只考虑“软件能不能完成功能”而要问“在真实温室环境中这个功能是以什么方式被触发的、被触发时其他系统是什么状态”。这个视角的转变直接决定了测试用例的有效性。4.2 数据采集比对如何科学评估控制效果的量化步骤控制效果验证不能靠肉眼观察必须用数据说话。我在现场项目里固定了一套数据采集比对的流程可以作为参考第一步布置独立的巡检级温湿度记录仪。每栋温室至少布3个点分布在温室前中后段、上中下层记录间隔设为1分钟连续记录72小时。第二步从环控软件后台导出同一时段的设定值、实际值、控制指令记录与独立记录仪数据做时间对齐。第三步计算三个关键量化指标控制偏差实际值与设定值的平均绝对偏差、超调量实际值超出设定值波动的最大幅度、稳定时间从控制动作发出到环境参数进入允许波动区间的时间。第四步针对偏差较大的时段做根因分析判断是算法问题控制策略不合理、执行机构问题风机风量不足、湿帘水泵流量低还是传感测量问题传感器安装位置不合理、数据漂移。这套流程做下来测试报告里的“温度控制基本正常”就会变成“在夏季工况下平均控制偏差0.8摄氏度最大超调1.6摄氏度稳定时间12分钟以内满足蝴蝶兰催花阶段的温控精度要求”——行业的汇报风格就是要用数字说话。4.3 现场联合调试中的敏感设备保护准则现场测试有一个底线原则不能因为测试动作影响作物的正常生长。特别是花卉温室种的都是要上市卖钱的商品花任何控制异常都可能导致不可逆的损失。在测试方案评审阶段我就坚持加上一条约定所有异常场景测试必须在专门的测试温室或空棚进行不允许在种植生产区做破坏性测试。实际操作中即便在同一种植区做正常功能验证也必须保护敏感设备。花房温室内的遮阳幕布、补光灯、环流风机都有明确的启停间隔限制频繁启停会缩短电机寿命灌溉设备一次开启时间不能太短否则供水压力波动会导致管路水锤现象热风机不能连续频繁启停压缩机需要保护延时。所以现场测试的执行计划里每一项控制指令的频率必须做预审核软件测试算出来的“开3秒关2秒再开3秒”这种用例在实验室里可以执行到现场就绝不能跑。我在项目启动会上一再强调这个原则软件可以重置重启设备坏了要换新的花死了损失的是农户一整季的收入测试人员要有敬畏心。5. 测试中的疑难杂症与排查实录那些年踩过又填平的坑5.1 典型问题一数据界面显示正常但控制逻辑一直不触发这个问题的表现是软件界面上的温度已经超过设定上限风机状态却一直不启动。一开始测试人员怀疑是控制逻辑写错排查代码后发现问题出在上位机界面和控制器之间的数据同步机制上。上位机显示的是从数据库读取的实时数据但控制器执行控制逻辑时使用的是内存中缓存的一份数据Cache的刷新策略有问题导致控制逻辑拿到的数据总是比界面数据“慢半拍”。这类问题的排查难度在于界面上看一切正常数据都对就是动作不触发。我的排查经验是先把数据链路拆出来端到端地追踪一份数据从传感器到界面、从界面到控制器内存的完整流转路径再对比不同环节的数据刷新频率通常会找到某个环节的缓存或订阅机制在做“坏事”。这种问题在仿真环境中很容易被漏掉因为仿真环境的数据变化规律比较理想化刷新频率差异不容易出现到了现场传感器数据每时每刻都在抖动缓存不一致的问题就会反复冒头。5.2 典型问题二远程升级后倒置的控制参数被“恢复出厂”某项目试运行期间现场的技术员在软件里把温度控制策略从“基于时间表”改成了“基于积温模型”并保存了参数。后来远程升级了一次软件升级完成后发现所有控制参数都回到了默认值技术人员前一天做的参数修改全部丢失。排查后发现远程升级包在打包时将配置文件也一并覆盖了而现场技术人员修改的参数存储在本地配置文件中MySQL数据库里只有部分参数做了持久化。升级过程中新版本的默认配置文件被推送下来直接把修改过的配置覆盖掉。这个问题的教训有两点一是升级包设计时配置文件要区分“出厂默认配置”和“运行时用户配置”升级过程中只更新程序文件不动用户配置二是测试用例里增加“升级前后配置一致性检查”在升级前记录基线配置升级后自动对比发现不一致立即告警。从那以后我把配置兼容性检查列入了远程升级测试的必测项再没出现过同类问题。5.3 典型问题三自动控制模式下偶发出现设备“打架”某一次现场联调中环控软件在自动控制模式下偶发出现热风机和湿帘同时开启的情况。热风机吹热风的同时湿帘在喷水降温这两种设备同时工作是极其矛盾的而且在冬季会造成严重的能源浪费。问题不是必现的观察两天才复现一次复现时也没有明显的规律。最终靠的是日志反查把控制软件的决策日志、设备执行日志、传感器采样日志按时序合并分析发现在一个特定时间窗口内温度降到加热阈值以下触发了“开热风机”同时湿度传感器因为湿帘残留水分的干扰读数瞬间跳高到触发“开湿帘”的阈值两个控制任务在不同线程里并行执行没有经过互锁仲裁设备状态瞬间翻转。修复方案分两层软件层面增加全局设备互锁仲裁模块任何控制指令下发前都要经过设备状态表的仲裁硬件层面在热风机和湿帘的接触器控制回路中增加硬线互锁即使软件发出错误的指令硬件也会强制阻止两个接触器同时吸合。这个案例我一直保留在项目总结里它清晰地说明了软件测试和硬件保护在可靠性设计中的互补关系——软件要做决定硬件要做兜底任何一层都不能丢。5.4 问题排查工具链日志、抓包、时间戳一个不能少温室环控系统的故障排查比普通信息系统更需要完善的可观测性。我建议项目组在测试环境预置以下排查工具链统一日志平台所有控制指令、传感器数据、报警事件以结构化日志形式记录时区分明时间戳精确到毫秒。Modbus抓包工具用于分析上位机与下位机控制器之间的通信报文确认指令是否有发出、控制器是否有应答。设备动作曲线工具将温度设定值、实际值和设备启停状态叠加绘制在同一张时间轴图上一眼就能看出控制逻辑是否正确。远程终端支持测试人员在远程查看现场工控机的运行状态在复杂问题排查时减少来回跑现场的频次。现场排查问题有一条铁律先对时间再对数据最后下结论。很多看似诡异的故障最后查出来就是设备本地时间与服务器时间差了十几秒导致日志时序错乱。所以现场测试的第一天第一件事就是统一全链路设备的时间同步这一步不做好后面所有排查都会事倍功半。6. 赋能农业数字化转型测试人员还能主动多做一步6.1 从“测软件”到“测系统”拓宽测试的价值边界参与温室环控软件测试的几年里我最大的体会是这类项目对从业者的要求已经超出了“写用例、提Bug、发报告”的传统范畴。因为一套环控系统的真正价值不只取决于软件写得对不对还取决于传感器布点合不合理、设备选型匹不匹配、网络传输稳不稳定、现场运维人员会不会用。任何一环掉链子软件做得再好也是白费。所以在测试过程中我会主动把测试范围往上下游延伸。上游延伸到需求评估验收标准是不是清晰、控制策略的设计是否符合作物生长的真实需要下游延伸到运维指导给现场技术员写一份“哪些按键不能乱动、哪些报警响起必须立刻去现场”的简明手册。这些工作表面上超出了测试的职责边界但实际落地效果非常明显——软件的问题依然由我来测但影响软件运行效果的外部因素我也能提前识别、提前规避。6.2 三类最容易收尾时扯皮的验收问题提前规避更省心这类项目在验收阶段的纠纷通常集中在三个话题上控制精度到底达不达标、异常情况下该由谁负责、测试数据算不算有效证据。与其到验收时争辩不如在项目启动时就把规则定好。第一类控制精度问题。建议在测试方案里明确以独立的第三方记录仪作为校准基准不以软件显示的数据作为判定依据控制精度必须在规定工况下用规定时间窗口内的数据来计算不能只看瞬时值。第二类异常责任问题。建议明确因传感器故障、网络中断、设备自身故障导致的环境失控不等于软件缺陷软件只要在异常发生后正确触发了报警并进入了安全模式就算合格。第三类测试证据问题。建议把测试记录做成可追溯的每个测试用例都关联到具体的时间戳、环境参数快照、日志片段。这样即便验收过去半年之后再有争论也有据可查。6.3 少走弯路的三条经验清单最后把我在多个温室环控项目里沉淀下来的经验浓缩成三条特别适合第一次接触这类项目的测试团队参考第一先搭仿真验证体系再进现场。宁可多花两周时间在仿真环境里把场景跑透也不要带着用例去现场边测边改现场一小时的代价远超实验室十小时。第二异常场景的用例数量至少要占用例总数的40%。温室环控软件在正常工况下表现都差不多拉开差距的恰恰是对偏差、故障、极端事件的应对能力。把传感器拔线、通信断连、断电重启、参数越界这些异常场景反复测透系统的可靠性会有一个肉眼可见的提升。第三控制效果的评估要形成闭环。不要只测完就出报告测试发现的控制偏差和振荡问题要推动算法团队或设备团队修复修复后再回归验证形成“发现—修复—验证”的完整闭环。只有这样软件越测越成熟而不是测完还是那个半成品。花卉温室环境控制软件测试说到底是在为农业的精细化生产建立一条安全底线。系统每稳定运行一天意味着几十亩温室内的作物可以在预设的环境中生长意味着农户可以少熬夜观察天气变化也意味着农业数字化转型这件事又往前迈了一小步。如果你正处在类似项目的测试岗位上希望这篇文章里的思路、方法和踩过的坑能帮你少走一些弯路。测试这条路上踩坑不可怕怕的是踩完之后没有记录、没有沉淀。