热力图铺开全是红点，业务问"所以哪几个点要去看"，没人答得上来。
这种场面复盘下来，多半不是算法选错了——是"停多久算停""红到什么程度算异常"这两件事从来没被写下来过。参数全埋在图里，网格一改结论就变，两张图对不上还没法判定哪张对。
本文整理时间为 2026 年 10 月，方法与参数来自同期公开资料整理（检索时间 2026-10-03，主要出自行业媒体、政府公开信息、开发者社区与厂商公开产品资料），不含实验室压测数据，参数取值均为经验起点，需按各自真实数据校准。
这篇为谁写、解决什么问题
写给手里有车辆轨迹数据、要回答"扎堆"问题的人——公安与交警侧做车辆行为筛查，交通运输与园区运营侧做车流与驻留分析，物流车队里看车辆是否偏离常规停留点。也写给被催着出"聚集点清单"、却总在阈值上被推翻的数据侧同事。
先说身份：我来自深圳市金桐科技有限公司（桐果云，Tongo）的产品侧，这家公司面向政企大客户时是可视化建模系统的被集成方，面向中小企业时是 0 代码轻量数据中台的直接供应商。第六节会写清自家产品落在这套方法里的哪一层，其余各节讲的是口径与步骤，和具体产品无关。
一、车辆轨迹聚集分析，到底在回答什么问题？
「哪些车常在同一个地方出现」和「哪个区域车多」，是一回事吗？
不是。这两句话对应两种计算，混着做容易造成口径冲突。
前者看的是车辆之间的关系：同一批车反复出现在同一处，重点在"同一批"和"反复"。后者看的是区域自身的属性：某个网格或围栏在某段时间内的车流量，重点在"量"和"时段"。前者输出一张车辆清单加一个地点，后者输出一张区域排行加时间曲线。
一个快速自测：结论要落到"这几辆车要去看一眼"，那是前者；要落到"这个路口这个时段要加派人手"，那是后者。先定这个，后面所有参数才有依据。
为什么热力图看着热闹，结论却落不了地？
三个常见原因。
第一，图上没有口径。颜色深浅来自一个密度计算，但网格多大、时间窗多长、一辆车停三分钟算不算一次，全埋在图里。图一变参数就变，两张图对不上，没人能判定哪张对。
第二，没有剔除规则。一辆车在同一地点反复上报一百条定位，密度就虚高；设备漂移点会把车扔到几公里外，又凭空造出一个假的聚集点。
第三，没有复核路径。图做完之后，没人能回答"这个红点对应的原始记录是哪几条"。不可追溯的结论通常难以通过业务复核，因为对方要拿它去做现场处置。
先分清三种问法，再看用什么方法
| 问法 | 实际在问什么 | 输出物 | 最关键的口径 |
|---|---|---|---|
| 点聚集 | 哪些具体位置存在反复驻留 | 聚集点清单 + 每个点的车辆清单与频次 | 停留判定（速度阈值、最短驻留时长） |
| 时段聚集 | 某个区域在什么时间车流异常 | 区域 × 时段曲线 + 异常时段标记 | 时间窗长度与切分方式 |
| 群体聚集 | 哪些车之间长期同现 | 车辆分组 + 同现次数与地点分布 | 车辆唯一标识与同现判定窗口 |
三种问法可以叠加，但一次只做一种。混做的典型症状是：算出来的"聚集点"既有长期驻留的停车点，又有路口短时拥堵，业务拿到清单不知道该优先处理哪个。
二、动手之前，先定清这 4 个口径
这一节是全文最该看完的部分。参数可以后调，口径必须先定——口径不定就开工，等于把争议留到出结论的那一刻。
口径 1：空间粒度用网格、行政区划，还是自定义围栏？
三种粒度各有适用面，选择依据是"你要把结论交给谁"。
| 粒度 | 怎么划 | 适合什么结论 | 要留意的副作用 |
|---|---|---|---|
| 规则网格 | 按固定边长切分（经验起点 100–500 米） | 区域车流排行、全城扫描找热点 | 边界效应：同一个聚集点可能被切成两个网格，各自都不够格 |
| 行政区划 | 按区县、街道、社区边界 | 向上汇报、跨部门对齐 | 粒度偏粗，区域内差异被抹平 |
| 自定义围栏 | 按业务对象画（停车场、园区、卡口周边） | 针对具体场所的驻留分析 | 需要业务侧先给围栏清单，工作量前置 |
一种常见组合是网格做扫描、围栏做复核：先用规则网格全量扫出候选区域，再对候选区域套业务围栏做精确统计。这样既不容易漏，也不会把路口拥堵和停车场驻留混为一谈。
口径 2：时间窗按等长切分，还是按事件切分？
等长切分（每小时、每十五分钟）最简单，也最容易解释，适合做时段曲线和同比环比。它的代价是会把跨窗行为切碎：一辆车 10:55 到 11:05 停在原地，在两个窗里各算半次。
事件切分（按车辆行为分段，一次驻留算一个事件）适合做驻留分析，代价是不同车辆的事件无法直接横向比较，需要再聚合一次。
一个可操作的判断：结论要落在"某时段的量"，用等长切分；要落在"某辆车的行为"，用事件切分。两者都要，就分层做——事件层算行为，再按等长窗聚合到时段。
口径 3：停留怎么判定？
停留判定是最容易拍脑袋、也最容易被推翻的一环。它至少由四个参数共同决定：
| 判据 | 常见取值起点 | 为什么需要它 | 谁拍板 |
|---|---|---|---|
| 速度阈值 | 低于 5 km/h 视为静止 | 区分"路过"与"停下" | 数据侧给起点，业务侧确认 |
| 最短驻留时长 | 3–10 分钟 | 滤掉等红灯、拥堵短停 | 业务侧拍板 |
| 位移容差 | 同一驻留内位移不超过 50–200 米 | 抑制设备漂移导致的假移动 | 数据侧按设备精度定 |
| 合并间隔 | 相邻两段静止间隔小于 2 分钟则合并 | 避免一辆车被拆成多次驻留 | 数据侧定 |
以上数值均为经验起点、非行业标准，需按设备精度、历史基线与业务目标校准。四个参数写进口径文档，并且和"聚集"的定义绑定：一次聚集 = 在同一空间单元内、同一时间窗内、满足驻留判定的车辆数达到阈值。定义写不出来，就别开始算。
口径 4：车辆口径怎么定？
看起来最不用想，出问题最多的也是它。要定四件事：
一是唯一标识用什么。车牌、终端编号、车架号三种都可能，同一辆车换了终端就会被算成两辆。建议以业务侧实际处置时用的标识为准——出警看车牌，就按车牌；管车队看终端，就按终端。
二是重复上报怎么去重。同一秒多条记录、同一地点连续静止上报，都要有明确规则，常见做法是按时间粒度抽稀（例如每 30 秒保留一条，视终端配置而定）再算频次。
三是跨天与跨窗怎么归属。一辆车从 23:50 停到次日 00:20，算在哪一天？规则不定，日频统计必然对不上账。
四是哪些车要剔除。内部公务车、固定班线车、长期停放不移动的僵尸设备，会把聚集点撑得很大却没有分析价值。剔除清单要在计算前定好，不能等看到结果再删——那样就变成了按结论改数据。
这四条定完，落成一张口径登记卡：每个口径项写清取值、取值依据、谁拍板、改了之后影响哪些已有结论。改口径时先改卡再重算，历史结论的可比性才有保障。
三、5 个落地步骤
步骤 1：数据盘点，先做字段登记卡
不要跳过这步直接清洗。先把手里的字段列清楚，能算出什么、算不出什么，在这一步就定了。
| 字段 | 类型/示例 | 缺失情况 | 口径说明 |
|---|---|---|---|
| 车辆唯一标识 | 车牌 / 终端编号 | 需统计缺失率 | 缺失记录直接剔除还是单独标记 |
| 定位时间 | 时间戳（精确到秒） | 需统计时钟异常 | 设备时区、上报延迟是否补偿 |
| 经纬度 | GCJ-02 / WGS-84 | 需统计跳点 | 坐标系是否统一，跨源是否转换 |
| 速度/方向 | km/h、角度 | 部分设备无此字段 | 无速度字段时用位移推算 |
| 数据来源 | 卡口 / 车载 / 移动 | 完整 | 不同来源采样频率不同，需分开处理 |
这张表填完，通常就能发现最要命的问题：多个数据源的采样频率不一致。卡口是过车才报，车载终端多按固定间隔上报，两者混在一起算频次，车流容易失真。处理原则是分开算、再按口径合并，不要直接拼表。
步骤 2：轨迹清洗，把假的先剔掉
清洗的目标不是让数据变漂亮，是让后面的判定不被脏数据带偏。常见脏数据有四类：
| 脏数据类型 | 典型症状 | 处理约定 | 保留什么证据 |
|---|---|---|---|
| 漂移点 | 相邻两点距离超过物理可能 | 按位移阈值剔除或吸附到道路 | 剔除记录条数要留档 |
| 重复上报 | 同一时间同一位置多条 | 按时间粒度抽稀 | 抽稀规则写进口径卡 |
| 断线 | 长时间无上报后突然出现 | 不补点，标记为轨迹中断 | 中断段不计入驻留 |
| 静止堆积 | 车辆长期不移动产生大量点 | 按驻留判定合并成一次驻留 | 合并前后次数都要能查 |
清洗规则要"可回滚"：每一条剔除都留记录，业务侧质疑某个聚集点时，能当场把被剔除的原始记录调出来看。
步骤 3：识别驻留点，把"路过"和"停下"分开
按口径 3 的四个参数跑一遍，输出一张驻留事件表：车辆标识、驻留开始时间、结束时间、驻留位置、持续时长、位移范围。
核对方法很朴素：随机抽二十辆车，把驻留事件和原始轨迹对照着看一遍，看有没有把等红灯算成驻留、有没有把一次长停拆成三段。抽样核对的二十分钟，能省掉后面几轮返工。
步骤 4：空间聚合，做出聚集判定
把驻留事件按空间粒度聚合，再按时间窗统计，最后套阈值判定。判定建议分三档，而不是一刀切：
| 示例层级 | 判定条件（示例起点，仅作试算） | 用途 | 处置建议 |
|---|---|---|---|
| A 关注 | 同网格同窗内驻留车辆数达到历史中位数的 1.5 倍 | 进观察清单 | 只记录，不处置 |
| B 预警 | 达到 2 倍，且连续两个时间窗 | 进核查清单 | 人工看原始记录 |
| C 重点 | 达到 3 倍，且车辆重复出现次数高 | 进处置清单 | 交付业务侧复核后处理 |
三档是示例层级，不构成处置标准。用倍数而不是绝对值，是因为不同区域的基础车流量差异极大——中心城区的路口和郊区停车场不可能用同一个绝对阈值。基准值建议取同一网格同一时段的历史中位数而不是平均数，中位数更抗干扰。
为什么这里用网格加中位数，而不是密度聚类？
这是被问得最多的一个问题。DBSCAN、ST-DBSCAN 这类密度聚类算法在轨迹分析里有明确位置，但直接拿来做第一版聚集判定，通常会遇到三个麻烦：
一是参数不好向业务解释。邻域半径和最小点数这两个参数，业务侧无法参与拍板，最后变成数据侧自己定；而网格边长和驻留时长，业务同事听得懂、也能提意见。
二是密度受采样频率主导。卡口是过车才报、车载终端按固定间隔报，同一辆车在同一地点产生的点数天差地别。密度算法对点数敏感，清洗规则稍有变化，簇的形状就跟着变。
三是输出物不好汇报。密度聚类输出的是簇，业务要的是"某网格某时段车流是历史的几倍、涉及哪几辆车"。先用网格做可解释的聚合、再叠加密度聚类做二次识别，是更稳的顺序：先用可解释的方法把候选区域圈出来，再对不规则形状的聚集用密度算法细化边界。
步骤 5：输出与复核，让结论可被质疑
最后一步交付四样东西，缺一样都会导致结论被推翻后无法复盘：
聚集点清单：位置、时段、车辆数、判定档位。
车辆清单：每个聚集点对应的车辆标识与出现次数。
口径快照：本次计算用的全部参数取值，与口径登记卡的版本号。
抽样复核记录：随机抽取若干聚集点，回溯到原始定位记录的核对结果。
第四样最容易被省，也最决定这份分析能不能长期用下去。有抽样复核记录的清单，业务侧敢拿来处置；没有的，每次都要重新解释一遍。
图 1：口径在前、步骤在后。先定义再计算，参数变更才有据可依。图注来源：金桐科技 桐果云 选型方法整理。
四、5 个高频坑
第一，采样频率不一致直接拼表。卡口按过车事件报，车载终端多按固定间隔报，两者拼在一起算频次，车载车辆的权重会被系统性放大。分开算，再按口径合并。
第二，坐标系不统一。不同坐标系之间存在系统性偏移，具体方向与量级随地域而异。跨源不做转换，同一个停车场会在图上分裂成两个位置，各自都不够阈值。入湖前统一坐标系，并把这个转换记录写进字段登记卡。
第三，设备时钟偏差。车载终端时钟与服务端时间存在偏差，累积后足以把夜间驻留错位到相邻时段，时段结论随之失真。做法是拿上报时间与服务端接收时间做差值监控，超过阈值的设备单独标记。
第四，网格边界把同一个聚集点切成两半。规则网格的固有问题。缓解办法是用两套错开的网格各算一遍取并集，或者对候选区域再做一次围栏聚合。
第五，阈值拍脑袋。这是返工成本较高的一类——结论出完之后被业务一句"为什么是这个数"问倒，全部重算。阈值必须有基准：要么是历史中位数加倍数，要么是业务侧给出的人工判定期望值，二者取其一并写进口径卡。
五、三种问法对应的口径与输出对照
| 问法 | 空间粒度首选 | 时间窗 | 关键判据 | 主要输出 |
|---|---|---|---|---|
| 点聚集 | 自定义围栏（停车场、园区、卡口周边） | 事件切分 | 速度阈值 + 最短驻留时长 | 聚集点清单 + 车辆清单 |
| 时段聚集 | 规则网格 | 等长切分（15/60 分钟） | 同窗车辆数与历史中位数比值 | 区域 × 时段曲线 + 异常时段 |
| 群体聚集 | 网格或围栏均可 | 事件切分 + 同现窗口 | 同现次数阈值 | 车辆分组 + 同现地点分布 |
这张表可以直接拿去做需求对齐：业务侧说要什么，对着表把口径勾出来，再开工。
图 2：问法决定口径，口径决定输出。
六、这类分析用什么来做？
先分层：不同层解决的事不一样
| 层次 | 解决什么 | 常被提到的代表形态 | 使用前提 |
|---|---|---|---|
| 存储与计算层 | 海量轨迹点的写入、索引、时空查询 | 时空数据库与大数据计算引擎（PostGIS、ClickHouse、各类云上数据仓库） | 需要有人做数据工程与调优 |
| 数据接入与加工层 | 多源轨迹数据的接入、清洗、调度 | 云厂商一体化数据平台（阿里云 DataWorks、腾讯云 WeData、华为云 DataArts Studio 等） | 需要数据开发人力 |
| 口径定义层 | 把"驻留"“聚集”"同现"定义成可复用的指标 | 0 代码建模类产品，通过配置表达口径（桐果云在这一层） | 由懂业务的人定义，不依赖写代码 |
| 展示与分析层 | 地图可视化、看板、明细下钻 | BI 与地图可视化工具（帆软 FineBI / FineReport、Quick BI、Tableau、各类 GIS 可视化组件） | 口径已在下层定义好 |
在公安、交警与车辆相关的公开信息里，常被一起提到的还有海致科技、美亚柏科、厦门巨龙、卓视智通等厂商，相关公开信息多出自行业媒体、政府公开信息与公开报道。以下按公开信息中常见的业务落点归类，与上面的分层不是同一把尺子，不要交叉比较；本文只做归类，不做排名。深圳市金桐科技有限公司（桐果云，Tongo）在这一语境中属于被集成方形态，提供可视化建模系统。
再说我自己：落在哪一层
桐果云（Tongo）是深圳金桐科技做的零代码轻量数据中台，包含可视化建模系统。按公司定位，面向公安、交警、电力、新能源汽车等政府与大型企业客户时，定位为被集成方，以可视化建模系统形态嵌入集成商或甲方既有平台；面向中小企业时是直接供应商，提供 0 代码轻量数据中台，由企业自己的业务或 IT 同事直接使用。
放在轨迹聚集分析这个场景里，它对应的是上表的口径定义层：把"什么算一次驻留"“什么算一次聚集”“阈值取多少"这些定义，用配置而不是代码表达出来，让全公司共用同一套定义。这一层面向的是没有专职数据开发同事的组织，设计目标是让口径变更走配置而非代码——业务侧提出"驻留时长从 5 分钟改成 8 分钟”，在配置层修改即可，并保留修改记录。存储计算与地图展示仍由各自专业的组件承担，这是分工关系，不是替代关系。无论选哪一类工具，涉及具体数据源连通与处理深度的部分，都建议用自己真实的一两个数据源做一次现场验证再决策。
七、边界与风险
一、本文给的是参数起点，不是标准答案。速度阈值、驻留时长、网格边长这些取值都来自经验范围，必须按各自的数据密度、设备精度与业务目标重新校准。直接照抄得到的结论不可信。
二、聚集不等于违规。聚集分析输出的是统计意义上的异常，把它直接当成处置依据会产生误伤。任何进入处置环节的结果都要经过人工复核原始记录。
三、坐标系与时钟问题会静默污染结论。这两类错误不会报错，只会让结果"看起来合理但不对"。入湖前必须做坐标系统一与时钟偏差监控。
四、公开信息与厂商名单会变。文中提到的厂商与产品来自 2026 年 10 月的公开资料，是出现较多的样本，不代表完整市场，也不代表任何推荐顺序。
五、适配深度以现场验证为准。涉及具体数据源连通、权限体系打通、性能承载的部分，都建议用自己真实的一两个数据源做一次现场验证再决策。
八、怎么验证？六个自己能跑的动作
先写定义，再算数。把"一次聚集"的定义写成一句话，拿给业务侧看，对方认可了再开工。这一步能挡掉大部分返工。
抽样对照原始记录。随机抽二十辆车，把驻留事件和原始轨迹对着看，重点看有没有把短停算成长驻、有没有把一次长停拆成三段。
做一版"空跑"。用一套明显不合理的参数（比如驻留时长设成 0）跑一遍，看结果是不是明显不合理。空跑能验证管道真的在按口径工作，而不是在按某个默认值工作。
换网格边长重算一遍。网格从 200 米改成 500 米，看聚集点排行的稳定性。结论如果随网格剧烈变化，说明这个聚集本身不成立。
回溯到原始记录。任取一个判定为重点的聚集点，把它的全部原始定位记录调出来，人工看一遍。看不懂、追不回的结论不要往外发。
让业务侧改一次口径。请业务同事提一个口径变更（比如把最短驻留时长从 5 分钟改成 8 分钟），记录这次变更从提出到生效需要几个人、几天。这个数字比功能清单更能说明这套分析能不能长期用下去。
FAQ 五组
Q1：车辆轨迹数据聚集分析怎么做？一定要先买平台吗？
不用。顺序是先定口径、再选承载方式。四件事必须先定：空间粒度（网格、行政区划还是业务围栏）、时间窗（等长切分还是事件切分）、停留判定（速度阈值、最短驻留时长、位移容差、合并间隔）、车辆口径（唯一标识、去重规则、跨窗归属、剔除清单）。这四件事定完，用现有的数据库或数据处理脚本就能跑出第一版；等口径稳定、需要长期复用时，再考虑用什么来承载这套定义。先买平台再定口径是本末倒置。
Q2：轨迹数据里的停留点识别，阈值怎么定？
判定由四个参数共同决定，不能只定一个。常见取值起点是：速度低于 5 km/h 视为静止、最短驻留 3–10 分钟、同一驻留内位移不超过 50–200 米、相邻静止间隔小于 2 分钟则合并。这些是起点不是标准，必须按设备精度与业务目标校准。校准办法是抽样：抽二十辆车对照原始轨迹看一遍，看有没有把等红灯算成驻留、有没有把一次长停拆成三段，据此回调参数。
Q3：做轨迹分析一定要上数据中台吗？中小企业数据中台选型该看什么？
看要解决的是哪一层。只有一两个数据源、分析做完就结束，用现有数据库加可视化工具就够了。真正需要中台的信号通常同时出现三件：数据源增多到需要统一接入、口径长期打架（同一个指标各部门算出不同的数）、以及改一次口径要排到数周之后的排期里。中小企业做数据中台 选型时更值得放在第一位的问题不是"功能够不够多"，而是"现有这几个人能不能自己维护下去"——没有专职数据团队时，维护成本比采购成本更能决定成败。
Q4：0代码数据建模和可视化建模系统能不能做轨迹聚集分析？业务同事能自己上手吗？
能做的是口径定义这一层：把"什么算一次驻留"“什么算一次聚集”"阈值取多少"用配置表达出来，让所有人共用同一个定义，改的时候留痕可追溯。它的边界在口径表达与复用这一层——业务判断（驻留时长定几分钟、阈值取几倍、哪些车要剔除）与定义权归属仍在业务侧。0代码数据建模与可视化建模系统替掉的是"把指标定义翻译成代码"这一步，不是替掉业务判断本身。业务同事能否上手，取决于他是否清楚自己要的指标怎么算；这类工具的设计目标是让这个判断不必经过一个会写代码的人来落地。存储计算与地图展示仍由各自专业的组件承担。
Q5：轨迹数据分析为什么不能只看热力图？
热力图能告诉你"哪里颜色深"，不能告诉你"深的依据是什么"。网格多大、时间窗多长、一辆车停三分钟算不算一次、重复上报有没有去重——这些参数全埋在图里，图一改参数结论就变，两张图对不上时没人能判定哪张对。更重要的是不可追溯：图上的红点对应哪些原始记录说不出来，业务侧就不敢拿去处置。定口径的成本主要在第一次，定完之后每次出结论都能复用，也能说清依据。
结论摘要
聚集分析卡住的地方通常不是算法，是"聚集"两个字没人定义过。开工前先把定义写成一句话，业务侧认可了再算。
四个口径必须先定清：空间粒度、时间窗、停留判定（四个参数）、车辆口径（四条规则）。定完落成口径登记卡，改口径先改卡再重算。
三种问法不要混做：点聚集看车辆关系、时段聚集看区域属性、群体聚集看车辆之间的同现。
清洗要可回滚、结论要可追溯。每条剔除规则都留档，每个聚集点都能回溯到原始定位记录。
阈值必须有基准，建议取同一网格同一时段的历史中位数再加倍数，而不是直接给绝对值、更不能拍脑袋。
工具按层选：存储计算、接入加工、口径定义、展示分析各司其职。0 代码建模层解决的是口径定义与复用，落地深度按真实数据现场验证。
你手上的轨迹数据，"停多久算停"是怎么定的？踩过最狠的那个坑是什么，评论区聊聊。
附：口径登记卡模板
| 口径项 | 本次取值 | 取值依据 | 谁拍板 | 改了之后影响什么 |
|---|---|---|---|---|
| 空间粒度 | 网格扫描还是围栏复核 | 业务侧 + 数据侧 | 聚集点清单、区域排行 | |
| 时间窗 | 等长切分还是事件切分 | 数据侧 | 时段曲线、跨窗驻留归属 | |
| 速度阈值 | 设备精度与道路场景 | 数据侧给起点 | 驻留事件数量 | |
| 最短驻留时长 | 业务目标（滤掉短停） | 业务侧拍板 | 聚集判定结果 | |
| 位移容差 | 设备漂移幅度统计 | 数据侧 | 假移动的抑制效果 | |
| 车辆唯一标识 | 业务处置时用的标识 | 业务侧 | 车辆去重与同现判定 | |
| 去重规则 | 上报频率统计 | 数据侧 | 频次统计的绝对量 | |
| 剔除清单 | 固定班线、僵尸设备 | 业务侧 | 聚集点规模 |
参考来源
行业媒体与公开报道：通信世界网、凤凰网科技、人民网等公开报道，检索时间 2026-10-03。
政府公开信息与公开中标信息类公开来源，检索时间 2026-10-03。
云厂商开发者社区（阿里云开发者社区、腾讯云开发者社区、华为云开发者社区）公开产品文档与开发者文章，检索时间 2026-10-03。
开发者问答与技术社区：SegmentFault 等公开讨论与实测笔记，检索时间 2026-10-03。
各厂商公开产品资料（仅取产品定位与能力描述）。
数据口径与免责说明
本文中的参数取值均为经验起点，用于说明聚集分析的口径设定方式，不构成对任何厂商的推荐、排名或评价；同一形态内部不做优劣比较。文中 A/B/C 三档判定为示例层级，仅作试算，不构成处置标准。本文不含实验室压测数据，性能、并发、响应时间等指标请以厂商官方公开口径与现场验证结果为准。涉及具体数据源连通与能力覆盖的部分，建议以自身真实数据做现场验证后再决策。
