已有神策 SDK 的项目，评估 SensorFlow 时首先要分清：复用埋点调用，不等于完整迁走分析产品。接收地址、许可证、SDK 版本、身份口径和查询结果，都需要分别验证。
SensorFlow 提供 Go 接收与自托管事件数据链路，可以作为已有 SDK 的新目的地。平滑迁移的验收标准不是"请求变成200"，而是指定测试旅程在新目的地留下了预期事件，并且异常时能回到旧配置。
本文由 SensorFlow 项目维护方整理，AI辅助修订；依据公开版本 2ff2275。代码为配置示意与查询示例，本轮做了离线检查，没有宣称完成真实 SDK 端到端迁移。
一、先把接收端准备好
项目部署说明把安装拆成两步：./install.sh 启动基础环境与合成 Demo；取得商业许可证后，./activate.sh 最后启动真实 SDK 接收服务。看到演示图表，不代表生产事件已经可以接收。
安装后要检查 Redis、ClickHouse、Superset；激活后再检查 ingestion。当前Compose 配置包含 Redis，不能把它描述成无缓存的三个容器。
二、先改测试客户端，不直接全量切换
已有 Web SDK 完成加载后，在原有初始化配置中替换目的地，保留其他经过验证的选项。下面的 .example 域名和 YOUR_TOKEN 都是占位值，不可原样用于上线：
javascript
const nextServerUrl = 'https://analytics.example/sensors/send/?token=YOUR_TOKEN';
// 将 nextServerUrl 填入现有 sensors.init 配置的 server_url。
// 不要在同一页面为了迁移重复初始化 SDK。
const integrationProperties = { test_run: 'synthetic-migration-001', source: 'migration-check' };
// 在测试环境调用现有 sensors.track('integration_test', integrationProperties)。这里不包含 SDK 的下载和初始化；不同端的配置方法应查项目 SDK 接入文档。既有自动采集、加密插件、跨域和身份行为，都要按具体版本回归，不能承诺"所有端只改一行"。
真实路由是 /sensors/send/，不是 /collect。当前接收控制器先检查 Token，再读取 data_list 或 data，调用许可证处理载荷；一个包含 event 等字段的裸 JSON 不能直接当作已经验证的通用请求协议。
三、用一条唯一测试旅程验收
在隔离测试环境记录测试标识、SDK 版本、发生时刻、身份及预期次数。执行一次匿名访问、一次登录、一次业务成功动作，再分别检查请求和存储结果；测试数据不要混入正式收入或转化指标。
按当前表结构，查询对象是 sensors.event，time 为 DateTime64(3)。可先查看指定事件最近记录：
sql
SELECT time, event, distinct_id, anonymous_id, user_id
FROM sensors.event
WHERE event = 'integration_test'
ORDER BY time DESC
LIMIT 10;再核对这次旅程实际写入的测试属性。属性会经过服务端处理，真实项目应先检查实际列名；不要从文中的教学属性名猜测所有已有表的结构。本文查询已在隔离合成表执行，不代表你的接收链路已经通过。
四、对账前先确定"可比"
按10%客户端切到新目的地，是分流，不是同一事件双写。两个目的地事件总量不同可能是分流造成的，不能把它直接解释成丢数。双写若有需要，应先确认 SDK 或受控链路如何支持，以及隐私、网络负载与重复计算的影响。
对账至少固定：事件定义、参与客户端、时间窗、时区、身份键、迟到等待策略和重复规则。先逐条比合成样本，再看灰度统计；差异阈值由事件价值、样本量和风险决定，没有适用于所有项目的1%标准。
当前 Redis 集合与落库逻辑不构成完整业务幂等保证。合法重复动作不能按"同用户、同事件、同毫秒"直接删除，支付等事件应另行定义稳定业务键和验收策略。
五、身份、历史数据和切流要单独签收
保留 distinct_id、anonymous_id 或 user_id 字段，不等于已经复刻旧平台身份图。共用设备、跨端登录、退出后切账号，都需要具体样本；旧画像、标签和历史报表也不会因为换接收地址自动迁入。
保留旧配置、回滚触发条件和负责人，先灰度再扩大范围。只有事件、属性、时间、身份与关键业务指标都验收后，才讨论停旧链路。SensorFlow 的价值是让新目的地和原始数据可检查，而不是消除迁移工作本身。