创业项目用 AWS Cognito 做认证，三个星期后我后悔了：一份技术选型避坑复盘

原文来源：Josh Karamuth — 作者为创业项目选型 AWS Cognito 做认证，三周后总结出"认证不该为省事买单"的技术选型教训。

给创业项目做技术选型，最容易踩的坑是什么？"反正已经在 AWS 生态里了，顺手用一下"——这个想法害人不浅。一位独立开发者在博客上复盘了自己用 AWS Cognito 做认证的三周血泪史，标题直接了当："我用 AWS Cognito 做了一个创业项目，我不会再这么干了。"

为什么选 Cognito：免费的诱惑

作者的团队需要给产品做认证，有人提议用 Cognito，理由非常典型："它本来就在 AWS 生态里，而且前 5 万个每月活跃用户免费。"

作者自己不是没经验的新手：他做过 Auth0 的认证、搞过 Firebase Auth，甚至徒手写过 JWT 方案。所以当时他的想法是：能有多差？

答案是：差到他把文档开满了十二个标签页，差到照着文档一步步做，密码重置流程还是跳转到错误的地方。

第一个坑：文档是给五种人看的

Cognito 的文档读起来像什么？作者形容：把三本完全不同的手册扔进搅拌机，再撒上一点过期的 Stack Overflow 答案。

AWS 想同时服务太多受众：想要理解底层身份协议的企业架构师、只想要一个登录表单的前端开发、需要原生 SDK 的移动开发。结果就是文档对任何人都没用——搜"custom attribute validation"，跳出来的页面先讲目录 schema，而读懂它需要你先看过另外四页你根本不知道存在的文档。

代码示例更是一场灾难：一半是旧版 JavaScript SDK 的写法，一些引用 Amplify v1 API，另一些用裸 AWS SDK。文档不告诉你每个示例对应哪个版本，你只能靠 import 语句当侦探。

第二个坑：Amplify v6 让你"重写"而非"升级"

这是让作者措手不及的地方。项目起步时 Amplify 还是 v5，认证流程写好了、测过了、上线了。几周后他回来修 bug，看到控制台里有弃用警告，想着"那就升个级吧"。

结果 Amplify v6 不只是改了几个方法签名——它重新架构了你和 Cognito 交互的方式。作者整个 UI 流程依赖的函数全部消失，被替换、被删除。迁移指南存在，但读起来像一张缺了一半地标的藏宝图。

作者把代码重写了。不是重构，是重写。生产环境里运行良好的认证逻辑，因为库维护者决定旧 API 不再是"被祝福的路径"而全部推倒重来。"这不是升级，这是劫持人质。"

第三个坑：本地开发是地狱

Cognito 是云端服务，意味着你没法在本地起一个实例离线测试认证流程，每次都要打真实的 AWS 端点。

社区有一些模拟方案（serverless-offline 插件、本地 Cognito 模拟器），但都是个人维护项目，保真度参差不齐。AWS 官方的态度基本是"对云端测试吧"——这建议很好，除非你在飞机上、网络不稳，或者只是想要不等待网络往返的快速迭代。

作者花了大把时间搭本地 mock，结果 mock 和真实行为对不上，bug 在本地溜过去、在 staging 环境冒出来。"本地开发的意义就是尽早发现问题，而 Cognito 在主动跟你作对。"

第四个坑：自定义？最多给你换个 logo

Cognito 自带的 hosted UI 能用，但想让它看起来像你的品牌？"你可以换 logo，可以在控制台里调一点 CSS。但布局、结构、整体感觉？那是 AWS 的房子，你只是租了个房间。"

想要任何超出基础的自定义，社区的标准建议是"用 SDK 自己建 UI"。作者吐槽：都这样了，hosted UI 到底给我省了什么？

第五个坑：邮箱登录配置，差点摔电脑

作者的产品只需要邮箱认证：邮箱注册、验证、设密码，完事。

他去用户池设置里把登录标识配置成邮箱，建好属性映射，创建注册流程——一切正常，直到他发现 Cognito 对"email"的处理取决于它是核心属性、别名还是自定义属性，而配置选项分散在控制台多个页面，依赖关系从不解释。

他犯了个小错误：把本该是标准属性的东西配成了自定义属性。改一下不就行了？不行。用户池属性一旦建成自定义属性，就永远是自定义属性。 如果你的认证方案依赖某些属性间的关系，而关系配错了，选项只有两个：删掉整个用户池重来，或者写一个复杂的迁移流程把用户搬到新池。

对生产应用来说，"直接删掉"不是选项。于是你开始写用户迁移脚本、处理新池的密码重置、向用户道歉——就因为控制台里一个下拉框太含糊了。

作者真正想说的：认证不是省钱的地方

作者强调，写这篇文章不只是抱怨。他想说的是：

"已经在生态里"这个理由很有诱惑力，但如果每次碰这个工具都让你痛苦，生态近亲关系毫无意义。 免费额度很吸引人，直到你算算跟文档搏斗、为破坏性 API 变更重写代码所花掉的工程时间。

他下次选型会先看开发者体验，而不是 AWS 服务集成便利性。"我们调试 Cognito 问题浪费的时间，够付好几年付费认证服务的钱了。"

他给正在评估 Cognito 的人一个具体建议：先做一个 PoC（概念验证）。要做就做个有分量的——包含自定义属性、邮箱验证、密码重置流程。感受一下，计个时，数数你最后开着的文档标签页。如果超过二十个，重新考虑。

文章最后有个很真实的细节：作者的项目还在用 Cognito，"陷得太深拔不出来了"，每次打开 AWS 控制台看到那个用户池，心里都有一股小小的怨恨，"像一个从不洗碗还老借你东西的室友"。

对我们的启示

对独立开发者来说，这篇文章的参考价值不在于"Cognito 垃圾"这个结论，而在于选型方法：

免费额度是获客工具，不是技术判断。 "前 5 万 MAU 免费"听起来诱人，但一个认证服务消耗的工程时间远超订阅费时，免费就是最贵的选项。

破坏性 API 升级是隐藏成本。 大厂托管服务的版本迭代不受你控制，选型时要问一句：它的重大版本更新有多频繁？迁移路径有多顺？Amplify v6 这种"整个 API 重写"的教训，等价物在 Firebase 的 Firestore 迁移、Supabase 的早期 API 变动上都出现过。

认证方案值得单独花时间评估。 它是用户数据的安全边界，也是你产品上线后最难替换的组件之一。与其上线后困在里面，不如一开始就做那个"带自定义属性的 PoC"——写登录、验证、重置三条流程，看真实体感。

如果一定要在 AWS 生态里做认证，社区常用的替代路线是：用 Cognito 只做用户池和令牌签发，UI 和流程自己写（很多团队最终都走向这条路线）；或者干脆选第三方认证服务。关键是把开发者体验放进决策权重里——它决定你未来两年每周要花多少时间跟这个系统相处。