雇主身份识别号（EIN）和社会保障号（SSN）都是九位的美国标识符，并且都可能出现在同一个表单里——但它们由不同的机构签发，遵循不同的格式，承担着差异极大的法律权重，并需要不同的校验逻辑。本文将带你梳理对开发者而言真正重要的差异：格式、校验、生成安全的测试夹具，以及哪种标识符应放在哪个表单字段中。
一段话总结
SSN 用于标识个人，由社会保障管理局（SSA）签发。EIN 用于标识商业实体，由美国国税局（IRS）签发。两者都是九位数字，但 EIN 写作 XX-XXXXXXX，SSN 写作 XXX-XX-XXXX。两者作为原始 9 位字符串都看似合理，这也是为什么格式（以及其背后的签发机构校验）是在代码中区分它们的最简单方式。
SSN——结构与规则
SSN 遵循 AAA-GG-SSSS 格式，由三部分组成：
- 地区号（AAA）：最初与签发州相关，部分区间被保留未分配。000、666 以及 900–999 不会被分配。
- 组号（GG）：在同一地区号内按记录在案的升序模式签发。00 这一组永远不会使用。
- 序列号（SSSS）：0001–9999，在一组内顺序递增。
最重要的实操准则是：某些地区号是被保留的，永远不会分配给真实个人。对测试数据最有用的区间是 900-99-XXXX 到 999-99-XXXX，它们在历史上用于促销用途并至今未被使用。我们的 SSN 测试格式生成器 即使用这些保留地区号，确保输出能匹配你的正则、但无法通过真实 SSA 校验。
EIN——结构与规则
EIN 遵循 XX-XXXXXXX 格式：
- 前缀（XX）：最初与签发该号码的 IRS 校区绑定。2001 年之后，前缀可用来判断签发分局，但并不严格对应公司的所在地。
- 序列号（XXXXXXX）：一个顺序递增的 7 位值。
与 SSN 不同，EIN 没有公开的"测试保留"区间，因此生成假 EIN 的目标是产出一个匹配格式的 9 位值；如果你的应用要识别 IRS 分局，可以带一个看起来真实合理的签发前缀。使用 EIN 生成器 可输出外观合理的合成 EIN，且永远不会与真实企业冲突。
对比表
| 属性 | EIN | SSN |
|---|---|---|
| 签发机构 | IRS | SSA |
| 标识对象 | 商业实体 | 个人 |
| 格式 | XX-XXXXXXX | AAA-GG-SSSS |
| 位数 | 9 | 9 |
| 测试保留区间 | 无官方区间 | 900–999 地区号 |
| PII 敏感度 | 高（企业） | 非常高（个人） |
| 存储监管 | 视上下文而定 | 强监管（GDPR、CCPA、IRS Pub 1075） |
正则校验
能分别接受两种标识符风格的纯格式正则：
// EIN：XX-XXXXXXX（或以非零开头的 9 位连续数字）
const EIN_RE = /^\d{2}-\d{7}$/;
// SSN：AAA-GG-SSSS，地区号需排除 000/666/900-999
const SSN_RE = /^(?!000|666|9\d\d)\d{3}-(?!00)\d{2}-(?!0000)\d{4}$/;注意 SSN 模式中的负向先行断言。它们会拒绝从未签发的区间，因此基于此模式的校验器会接受真实 SSN（以及保留地区号的测试 SSN，取决于你划定的边界）并拒绝明显的无效输入。在测试中你往往想要相反的结果——只接受 900–999 保留区间——从而可以确保不会有任何真实 SSN 进入预发数据库。把先行断言反转过来：
// 仅测试 SSN：AAA 必须为 900-999，GG != 00，SSSS != 0000
const TEST_SSN_RE = /^9\d{2}-(?!00)\d{2}-(?!0000)\d{4}$/;带自动识别的 JavaScript 校验器
function classifyIdentifier(value) {
const v = String(value).replace(/\D/g, "");
if (v.length !== 9) return { type: null, error: "must be 9 digits" };
const fmt = `${v.slice(0, 2)}-${v.slice(2)}`;
if (EIN_RE.test(fmt)) {
return { type: "EIN", formatted: fmt };
}
const ssn = `${v.slice(0, 3)}-${v.slice(3, 5)}-${v.slice(5)}`;
if (SSN_RE.test(ssn)) return { type: "SSN", formatted: ssn };
return { type: null, error: "format mismatch" };
}这是最安全的自动识别方式。真实 SSN 与 EIN 都能通过格式校验；在表单中收集哪一种输入是业务决策，不是解析技巧。
何时在表单中使用哪一个
使用 SSN 字段的场景……
- 你出于信贷、雇佣或代扣税款目的向个人采集（例如薪金入职、租户审查、贷款申请）。
- 你的合规团队已明确授权 SSN 存储，并配备相应的加密、访问控制和文档化的数据留存策略。
使用 EIN 字段的场景……
- 你要将一家企业作为客户、商户或分包商入驻（W-9 采集、B2B SaaS 注册、支付处理方 KYB）。
- 你需要就该实体向 IRS 报送 1099-MISC 或 1099-NEC。
绝对不要把两者混入同一字段
一个会静默接受 SSN 或 EIN 任一的"Tax ID"输入是一个 UX 陷阱——表单将不知道该套用哪条合规规则，你的数据团队也无法判断一条记录究竟是人还是企业。请使用分开的输入字段。
为测试生成安全的假数据
指引用法是：测试数据必须永远不能通过真实系统的校验。对 SSN 而言，这意味着从 SSA 公开确认未使用的 900–999 地区区间中抽取。对 EIN 而言没有对应的 IRS 规则集，因此你的表单接受的每一个 EIN 都可能是真实企业标识符——切勿把随机生成的 EIN 存入会调用 IRS 或第三方 KYB 厂商的系统中。
// 拉取安全的测试 SSN
fetch("/us-address/api/v1/ssn?count=10", {
headers: { Authorization: `Bearer ${KEY}` }
})
.then(r => r.json())
.then(res => res.data); // 10 个保留区段 SSN
// 拉取合成 EIN（仅匹配格式）
fetch("/us-address/api/v1/ein?count=10", {
headers: { Authorization: `Bearer ${KEY}` }
})
.then(r => r.json());这两类输出在你的表单看来都可信并能通过你的正则，但 SSN 值无法通过真实 SSA 校验，EIN 值则是随机字符串，几乎不会与真实企业冲突。
值得了解的合规要点
如果你的应用会存储任一种标识符，你很可能受以下具体法规约束：
- GLBA 及各州数据泄露法在许多司法辖区把 SSN 与 EIN 都视为个人信息。
- IRS Publication 1075 规定了联邦税务信息（包括 SSN）的处理规则。
- GDPR：任何国籍的 SSN 都属特殊类别个人数据，需要合法依据并按设计进行保护。
- PCI DSS 并不直接约束 SSN/EIN，但如果其中任一标识符与持卡人数据并存，合规范围就会扩大。
在上线采集 SSN 或 EIN 的表单之前，请与法务与安全团队确认存储、加密、访问日志与留存策略已文档化。如果还没就绪，你可以生成测试数据并搭建表单，但在它们就绪之前不要切换到生产存储。
总结
开发者的精简版要点：SSN 标识个人、EIN 标识企业，两者均为 9 位数字但格式不同，两者都属敏感数据——但 SSN 受到的监管严格得多。请分开校验、分开采集到不同字段；测试时从 SSA 的 SSN 保留区间（通过 SSN 测试格式 工具）与仅匹配格式的合成 EIN（通过 EIN 生成器）中取值。如此便能让你的夹具覆盖每一条正则分支，而又绝不会冒触及真实个人数据的风险。