避坑第一课：别被「全栈」平台忽悠了——功能边界要清晰

选设备身份治理平台的时候，我见过太多人一上来就问：「你们是全栈的吗？」

好像「全栈」就等于「好」。其实这是个挺危险的信号。

我自己的习惯是，一听到「全栈」两个字，反而会多问几个为什么。你想想看，一个平台如果真的什么都能做——从芯片级安全到应用层认证，从设备注册到数据治理——那它的每一块真的都能做到专业水准吗？

「全栈」背后的三个陷阱

说白了，「全栈」这个词在设备身份治理领域，很多时候是个营销话术。我总结了一下，主要有三个坑：

1. 什么都做，什么都不精——每个功能模块都浅尝辄止，深度不够。
2. 集成成本被低估——号称「开箱即用」，实际对接时发现各种接口不兼容。
3. 升级路径模糊——平台一旦扩展，旧功能可能被废弃，迁移成本极高。

嗯，这里要注意。不是所有「全栈」都不好，关键要看它的功能边界是否清晰。一个负责任的平台，应该明确告诉你：哪些是我擅长的，哪些需要你配合其他工具来完成。

功能边界：一张表说清楚

我个人习惯在选型前，先画一张功能边界表。把平台的能力分成三层：核心能力、扩展能力、边界外能力。这样一对比，谁在吹牛，谁在说实话，一目了然。

你看，真正专业的平台，会主动告诉你它的边界在哪。而不是什么都往自己身上揽。

如何判断一个平台的功能边界是否清晰？

我建议你从三个维度去拷问：

• 文档的诚实度——文档里有没有明确写「本功能不支持 XX 场景」？如果全是「支持」「兼容」「覆盖」，反而要警惕。
• API 的粒度——接口是粗粒度的「全量同步」，还是细粒度的「按需查询」？细粒度接口说明平台对自身能力有清晰认知。
• 故障时的表现——我问过很多供应商：「如果密钥分发模块挂了，会影响设备注册吗？」能明确回答「不会」的，才是边界清晰的平台。

一张图看懂功能边界

下面这张图，是我在项目里常用的功能边界分析框架。它帮你快速定位一个平台到底「全」在哪，「不全」在哪。

选型时的三个「灵魂拷问」

最后，我建议你在选型会议上，直接问供应商这三个问题。能答上来的，才是真功夫：

1. 「你们的密钥轮换功能，支持哪些算法？如果不支持国密，你们打算怎么补？」——看对方是直接说「不支持」，还是含糊其辞说「后续版本规划」。
2. 「设备注册的并发上限是多少？超过之后会发生什么？」——边界清晰的平台，会给你一个明确的数字和降级策略。
3. 「如果我只想用你们的证书管理模块，其他功能不用，API 能独立对接吗？」——能独立对接的，才是模块化设计。否则就是个大泥球。