一、问题定义：位置数据的归属，比定位精度更难谈 [P1]
1.1 被忽略的第三类问题：数据在谁的机器上
谈人员定位系统，技术讨论几乎总从定位精度开始：室内能到几米、刷新间隔多少秒、弱信号怎么补点。这些重要，但只覆盖了项目决策链的前半段。真正让方案在末期推翻重来的，往往是另一个问题——采集到的位置数据存在谁的服务器上，由谁运维，出问题时谁能看见。部署形态之所以构成独立的技术分支，是因为它不只关乎“买服务器还是租服务器”，而是一并决定了三件架构层面的事：数据在链路上跨越了几道边界、系统由谁承担运维与升级责任、客户要把既有系统接进来时接口落在网络的哪一侧。把它笼统归入采购流程处理，往往是项目在技术评审阶段才暴露返工的原因。
1.2 本文要回答的技术问题
本文以一套外勤人员定位云平台的终端用户手册与版本功能说明作为真实案例背景，把部署形态当作单一技术分支来拆解，不做功能罗列，也不做厂商对比。全文围绕四个问题展开：两种形态的链路差异在哪里；它们分别能承载什么；数据可见性边界如何落地；什么条件下该选哪一种。资料未给出的参数一律标注“以厂商资料为准”。
二、技术原理：两种部署形态的链路结构 [P2]
2.1 两种形态的链路分段一一对应
先解释两个术语。分布式 SaaS 指软件由厂商统一部署运维、多家客户以租户身份共享同一套系统资源；本地化部署指平台软件与数据存储运行在客户自己的服务器上，由客户自行部署运维。所谓“部署形态”，说的就是这套系统最终落在哪一类基础设施上。
两种形态在链路结构上完全对应，都可拆成四段：终端层采集位置点与事件，网络层把数据送出，平台层负责判定与核算，集成出口层把结果交给客户的其他系统。差别不在有没有这一段，而在这一段跑在哪里。分布式 SaaS 下，平台层与集成出口层位于厂商云侧，位置流经蜂窝或公网穿出园区；本地化部署下，四段全部位于客户内网之内，数据不出园区。
figV26_deploy
图 1 有一个容易被忽略的细节：本地化部署的“集成出口”同样在内网里。客户的考勤、工单、报表系统一般也在内网，因此本地形态下把位置点与业务单据做事务一致性反而更容易；而 SaaS 形态的接口在公网侧，客户内网系统要消费它，就必须自己解决网络出口、鉴权与带宽。同一句“提供开放标准 API 接入”，在两种形态下的工程含义并不相同。
2.2 差异真正集中的三个位置
排除相同点后，差异集中在三处。其一是平台的位置，即数据最终沉淀在谁的存储里，这决定了数据主权的归属与审计落点。其二是网络边界的位置，它决定集成出口要跨几道网、出口与带宽由谁提供。其三是容量与规则上限的计量口径：一种按时间档位给保留期，另一种按容量给可保存时长，两者不能直接换算，第三章具体展开。
三、方案对比：逐维度看清差异 [P3]
3.1 对比表
下表按七个维度对比两种部署形态。表中的功能名与数字均取自平台手册与版本功能说明，未覆盖的参数标注“以厂商资料为准”，不做推测。
figV26_table_deploy
3.2 三处需要换算而不是照抄的地方
其一，接入规模。参考平台的 web 端形态为分布式 SaaS，支持百万接入量；本地化部署的接入能力由客户自有服务器规格决定，资料未给出单机容量指标，需按厂商资料并结合实测压测确认。把“百万接入量”直接套到本地形态，或反过来用云端容量规划本地服务器，都会得出错误结论。
其二，存储与保留口径。云端按时间档位给出保留期：经典版 3个月、标准版 6个月、旗舰版 12个月。本地化部署则按容量给口径：最大支持32个电子围栏，数据保留时间为大约500G可保存一年时长数据。两者计量维度完全不同——前者是时间，后者是容量，而位置数据同时产生时间序列与空间点，单条占用随采样频率、轨迹点数与事件数量变化。要把“500G 能存一年”换算成“能回溯几个月”，须先用真实业务量测出单日增量。
其三，围栏与规则上限。云端按版本给出电子围栏数量：经典版 8个、标准版 16个、旗舰版 32个；本地化部署的资料直接给出最大支持32个电子围栏，但未按版本分档，具体以厂商资料为准。这里有个易踩的坑：围栏数量只是规则条数，实际规则复杂度还取决于嵌套层级、等级设定与判定方式。同一块物理区域，用一个多边形表达和用三级嵌套表达，对系统的规则消耗是不同的。
四、技术细节：授权链、容量口径与集成出口 [P4]
4.1 账户分层与数据可见性边界
部署形态解决数据放在哪里，而“谁可以看”是另一条独立但必须一起设计的链路。参考平台把账户划为四种类型：厂家、经销商、组织（公司）、个人。厂家用于接入系统设备，可添加设备供测试；经销商是销售中间人，负责销售设备并提供服务；组织（公司）与个人是终端用户。配套概念还有：用户相当于个人，可关联多个账户；角色相当于职务；权限相当于职能；组织结构相当于部门设置，最高支持4个层级。
这套分层直接对应一条数据可见性边界：为符合国家相关法律，保护终端用户隐私权限，厂家和经销商不能直接查看终端用户的数据，如需查看需要得到终端用户的授权。它的意义在于让“部署形态”与“数据可见性”成为正交的两件事——不论平台跑在厂商云还是客户内网，授权链逻辑完全一致，差别只在边界物理上落在哪一侧。选型时把两者混为一谈，就会误以为选本地部署就自动解决了数据权限问题。
另一条与部署形态无关的规则同样重要：系统所有监控数据都基于监控对象（人员），修改绑定设备后原数据依然保留，未绑定监控对象的设备为库存设备，不记录数据。这意味着人员换设备、离职归档不会造成历史数据断档，数据始终归属于人而非设备。把“数据跟着人走”纳入考虑，才能对历史轨迹的可查询性做出正确承诺。
figV26_sovereignty
4.2 两种形态下的容量计量口径
两种形态给出的容量约束不是同一种语言。本地化部署要回答“这台服务器能承载多少条规则、多长时间的数据”，对应约束是最大支持32个电子围栏与大约500G可保存一年时长数据；云端要回答“我的规模下保留期与规则上限如何取舍”，对应约束是 8个/16个/32个 的围栏档位与 3个月/6个月/12个月 的保留期档位。这两组数字都是上限而非承诺值：围栏上限为 32个 不意味着应建满 32个，保留期 12个月 也不意味着所有数据都会留满——实际占用取决于绑定人员数、上报频率、事件密度，以及是否启用轨迹比对这类高数据量功能。因此两种形态下都应先做小规模压测，用真实业务模型测出单日数据增量，再倒推能支撑的规则条数与回溯时长，而不是拿上限值直接做规划。
4.3 集成出口：接口、导出与推送
集成出口有三类通道，落点各不相同。其一是开放标准 API 接入，两种形态均提供，是把位置点与管理事件接入客户既有系统的主通道，也是架构上值得优先打通的通道。其二是模板化导出，参考平台支持按上传的表格模板导出数据，例如考勤表、轨迹表；这条通道看似朴素，却是更换平台时唯一可靠的迁移路径，应当在项目初期就配置好并保持使用习惯，而非等项目结束时临时补。其三是报警推送，顺序为 web → 微信 → 短信 → 邮件（邮箱需要客户定制），只要节点上有一种推送成功，则停止推送以节省资源。
三条通道放在一起，部署形态的工程差异就清楚了。SaaS 形态下 API 与推送都从云侧出发，客户内网系统消费它们需要自备出口与带宽；本地化部署下 API 与客户业务系统同处内网，事务一致性更容易，但要把数据开放给客户外部的第三方系统，出口与带宽同样要客户自备。本地化部署并不是“不要考虑出口”，而是把出口从公网侧挪到内网侧，责任主体从厂商转移给客户。
4.4 设备侧的数据行为同样需要写进方案
有几条设备与人员的状态规则直接影响数据在两种形态下的连续性，方案里应当写明。设备在平台上线则为激活，超过测试期不续费，则设备不能在平台正常使用——续费节奏与数据连续性是绑定的。启用与停用都从第二天开始，考勤计算会自动过滤掉停用设备的数据，停用后设备不再显示、不参与实时统计，考勤不再继续处理。人员存档用于保存离职人员的信息，点击存档后人员会自动和设备解绑，恢复则需重新绑定设备。这几条规则决定了历史数据的可见范围，也决定了切换部署形态时哪些数据需要迁移、哪些本就不该迁移。
五、局限与边界：两种形态都不解决的问题 [P5]
5.1 分布式 SaaS 形态的边界
SaaS 形态的代价先在数据边界。位置流必须穿出园区边界，这是链路的物理事实，与协议如何加密是两件事；交给合规审查时需要说清数据在哪一侧、由谁保管、终端用户如何授权，而不能只给一份加密方案。其次是运维依赖：平台版本节奏、故障恢复与容量规划由厂商负责，客户可控范围有限，方案应明确故障响应路径与责任边界。再者是弹性与固定成本的取舍，弹性一侧是云端按版本档位给能力上限，另一侧是本地服务器需客户一次性规划硬件。
5.2 本地化部署形态的边界
本地化部署的边界先在规模。资料给出的约束是最大支持32个电子围栏与大约500G可保存一年时长数据，接入能力由自有服务器规格决定且未给出单机容量指标，这更适合人员规模明确、增长可控的场景，而非需要弹性扩容的运营型场景。其次是运维成本：平台的部署、升级、备份与故障排查都落在客户身上，是长期人力投入而非一次性采购。再者是网络出口，接口与推送虽在内网，开放给外部系统时出口与带宽仍需自备。还有版本能力分档，资料未按版本区分能力，标准版与旗舰版的功能差异如何映射到本地形态，需以厂商资料为准。
5.3 资料未覆盖、需要向厂商确认的部分
为免误导，以下几项本文不做推断：两种形态的部署环境要求与硬件配置清单、单机能承载的终端接入数、内存与存储推荐规格、本地部署的版本能力与云端各档位的对应关系、以及本地形态下升级与备份的具体机制。这些都需向厂商确认，资料未给出即标注“以厂商资料为准”。还需说明的是，部署形态解决的是数据位置与运维责任，它不改变定位技术本身的精度上限，也不构成对系统能力的额外保证。
六、结论：给开发者的部署选型判断标准 [P6]
6.1 小结：部署形态是架构决策，不是采购细节
回到标题：人员定位系统的部署形态与数据主权，说的其实是同一条链路上的两件事。部署形态决定平台层与集成出口层跑在谁的机器上、位置流跨越几道网络边界；数据主权则由账户分层与授权链机制保证，它在两种形态下规则一致，只是物理落点不同。把这两件事放回同一个设计过程，才能得到既可落地也可审计的方案。
6.2 六条可执行的判断标准
如果要把本文压缩成一份可执行清单，建议按以下六条顺序推进。其一，先定数据边界：位置数据是否允许出园区，允许则云端优先，不允许则直接进入本地形态评估，不要在两者之间反复。其二，再定规模模型：用真实业务量测出单日数据增量，再决定是接受按时间计的保留期档位，还是按容量做本地规划。其三，把规则复杂度一并评估，围栏数量、嵌套层级、等级设定与判定方式都要计入，条数只是复杂度的其中一个维度。其四，权限设计前置，账户四类分层、组织结构 4个层级、角色与权限的委派方式在项目启动时就定好，授权链规则不随部署形态改变，晚设计必然返工。其五，把集成出口当成一等公民，优先打通开放标准 API 接入，同时把模板化导出用起来，作为未来更换平台的迁移通道，出口位置与带宽责任在方案里写明归属。其六，把设备侧的数据行为写进方案，上线即激活、续费节奏与数据连续性绑定、停用与存档从次日起影响考勤与统计、监控数据基于人员且改绑设备后原数据保留——这几条决定历史数据在切换时该迁什么、不该迁什么。做到这六条，部署形态就会从“默认选云”变成一次经得起追问的架构决策。
