「一迁移号码就立刻被封」听起来像行业铁律。Meta 并未公布投诉阈值、消息条数或「休息一天再预热」作为官方要求。这不代表不必谨慎——只是规则的来源不同。
换手机后 WhatsApp 会重新生成加密密钥并验证设备——Meta 有文档记载。但「迁移 + 立刻群发 = 按固定规章自动封号」不是官方文档，而是多账号运营者的集体经验——见 迁移封号风险。下文区分官方确认、仅作经验法则的部分，以及混为一谈对活动规划的危害。
误区。 听起来像技术规章：账号迁移加立刻群发 = 系统识别的经典 spam 模式，即使老号也会封；对策——正常用一天、预热一天，再开跑。
正解。 无官方佐证。Meta 不公布「换设备清零信任」、具体等待小时数或触发封号的消息阈值——见 封号机制。已确认：换设备会重新生成端到端密钥并启动 Device Verification——防账号被入侵的保护机制，Meta 不公开评分细节。「休息一天 + 预热一天」是运营者经验建议——逻辑类似 解封后预热——不是 WhatsApp 官方规则。当作合理谨慎，不要当保证。
WhatsApp 为 Signal 协议创建新的端到端加密环境，会话绑定新设备。这是所有用户共用的安全架构，不是对群发者的惩罚。
另有 Device Verification——防设备被入侵和恶意软件。Meta 确认存在，但不说明如何评估具体会话风险。论坛上的小时数、条数阈值应视为猜测，不是成文规则。
Meta 支持用同一号码迁移——过程中不涉及换 SIM。两条主路径：内置 Transfer Chats，或从 Google Drive（Android）/ iCloud（iOS）备份恢复。
官方工具或备份恢复是 Meta 推荐的迁移场景——不能保证免于任何限制，但应优先于通过非官方软件搬 token。
社区习惯：换设备后不要在最初几分钟就上大群发。常见流程——先正常使用（收 inbound、与真实联系人聊天），再逐步恢复惯常发送量。
另一条：不要同时改多个变量——手机、IP、接入国家、SIM——见 代理常见错误与 多号代理配置。同时变的因素越多，越难判断是什么影响了账号，前几天越应谨慎。
以上均为社区实践，非 Meta 成文规章。论坛「10–15 条安全」「第三天 80–100 条」不是官方上限。
WhatsApp Business API（Cloud API）没有「换到另一部手机」——号码跑在 Meta/BSP 云端，不绑物理设备——见 WABA 说明。可随意换 CRM、集成商、访问 token——没有「换硬件」层面的技术封禁，因为栈里没有硬件。
实践中至少两点无统一答案。
其一——QR 扫码（Multi-Device、附加设备）算不算需要同样谨慎的「迁移」？有人视为无需静置；有人认为新 Web 会话立刻群发与完整迁移同样危险。无共识。
其二——应用内「更改号码」（Change Number）会把部分账号数据迁到新号。若同时换设备，有人视为更温和，有人视为双参数变更的最大触发。官方无数据支持任一立场。
论坛描述：某机构把信任账号迁到新工作机，几乎立刻对 温名单 做计划内群发——账号很快受限，恢复要数天。另一例：多账号运营者把一批 profile 迁到新设备和代理，前几天不急于群发，逐步恢复量级——无一受损。
具体数字是论坛窄场景观察，不可当可复现统计或上限。但「猛开 vs 渐进」的对比仍有参考价值。
「老号换手机不会被封。」 账号年龄本身不保证豁免——Meta 不公布按号龄的「免疫」。
「Meta 要求迁移后等两天。」 官方文档无此建议——是社区做法。
「迁移会自动清零账号声誉。」 未证实。已证实的是换设备会启动面向所有用户的标准保护机制。
「不恢复备份一定受罚。」 未证实。官方迁移是推荐路径，非唯一，也不给保证。
「WhatsApp Business API 有同样问题。」 没有——物理换机只涉及普通 App；Cloud API 没有「换设备」概念。
下次换设备前——记录同时变几个参数：手机、IP、SIM、国家。一次变的越少，事后越容易判断是什么影响了账号。
实用规则：
迁移后的谨慎是运营者的合理习惯，不是 Meta 的规章——别把两者混为一谈。
