1. 项目概述这不是又一个“云平台宣传稿”而是一线开发者用三个月真实项目踩出来的路AWS Amplify 这个名字过去两年在前端圈子里出现的频率几乎和“微服务”“Serverless”一样高。但很多人点开官网文档看到一堆 CLI 命令、GraphQL Schema 定义、Auth 配置项第一反应是“这到底是帮人省事还是把简单问题复杂化”我去年底接手一个内部工具项目——要给销售团队快速上线一个带用户登录、客户数据录入、文件上传和实时状态更新的轻量级 SaaS 应用后端不能动现有 Java 微服务集群前端团队只有 2 人交付周期压到 6 周。我们试过纯 React 自建 Express API 手搓 Cognito 集成两周卡在跨域、Token 刷新、S3 签名失效上也试过 Firebase结果发现权限模型和我们已有的 RBAC 规则对不上改起来比重写还累。最后咬牙切齿地翻出 Amplify 文档从amplify init开始用它搭出了整套后端能力——不是“辅助”是真正意义上的全栈闭环。它没消灭复杂性而是把复杂性重新打包、分层、封装并把最常踩坑的环节比如 Auth 的 OAuth 流程、API Gateway 的 CORS 配置、S3 的预签名 URL 生成变成一行命令或一个勾选框。它解决的从来不是“能不能做”而是“能不能让前端工程师在不查 AWS 控制台、不读 IAM Policy 文档、不配 CloudFormation 模板的前提下安全、可复现、可协作地交付生产级云后端”。适合谁不是给 DevOps 工程师看的而是给那些被业务催着上线、手边只有 VS Code 和 npm、却要为数据安全、访问控制、CDN 缓存、边缘函数负责的全栈实践者。关键词就三个Amplify CLI、GraphQL API、托管式 Auth——它们不是功能模块而是你每天打开终端时最先敲的那几行命令。2. 全栈架构设计逻辑为什么 Amplify 不是“胶水”而是“新骨架”2.1 传统全栈开发的隐性成本才是真正的瓶颈很多人以为全栈开发的难点在技术深度比如搞懂 Lambda 冷启动、优化 DynamoDB 分区键、调优 CloudFront 缓存策略。但实际项目里80% 的时间花在“连接”上前端怎么安全拿到后端 TokenAPI Gateway 的请求体怎么映射到 Lambda 的 event 参数S3 上传的 presigned URL 怎么保证只允许特定用户、特定前缀、特定过期时间这些不是单点技术问题而是跨角色、跨工具链、跨环境的协同断点。我见过太多团队前端写完 React 组件等着后端发来 Swagger JSON后端写完 Spring Boot等着 DevOps 配好 CI/CD PipelineDevOps 配完 Pipeline发现前端传来的 CORS 配置漏了 OPTIONS 方法……这个链条里任何一环出错都得拉三个人开会半小时。Amplify 的核心设计哲学就是把这套“人肉协调流程”变成“机器可执行的声明式配置”。它不替代 AWS 服务而是用一套统一的抽象层Amplify CLI amplifyconfiguration.json backend/amplify-meta.json把 Cognito User Pool、AppSync GraphQL API、S3 Storage、Lambda Function、API Gateway 这些底层服务映射成前端可理解的编程接口如Auth.signIn()、API.graphql()、Storage.put()。关键在于这个抽象层不是黑盒——所有生成的 CloudFormation 模板都明文存在本地你可以随时修改、审查、提交到 Git。它既给了前端“开箱即用”的速度又保留了“按需定制”的掌控力。这不是偷懒而是把重复劳动自动化把注意力聚焦在业务逻辑本身。2.2 Amplify 的三层抽象模型CLI 是入口Category 是积木Transformer 是引擎Amplify 的能力不是平铺直叙的而是严格分层的。最外层是CLI 工具它是你和整个体系交互的唯一入口。amplify add auth不是调用某个 API而是触发一个向导引导你选择登录方式Email/SMS/Google/Facebook、是否启用 MFA、密码策略、用户属性等然后自动生成对应的 Cognito User Pool 配置。中间层是Category类别这是 Amplify 的核心积木单元。目前官方支持 8 大类auth身份认证、apiGraphQL/REST API、storageS3/NoSQL、functionLambda、hosting全栈托管、analytics分析、notifications推送、predictionsAI 预测。每个 Category 都有自己的一套 CLI 命令、本地配置文件和生成的 CloudFormation 模板。最内层是Transformer转换器这是 Amplify 的“大脑”。当你运行amplify pushCLI 并不直接调用 AWS API而是先调用 Transformer把你在schema.graphql里写的 GraphQL Schema比如type Todo model auth(rules: [{ allow: owner }])结合amplify/backend/api/name/parameters.json里的参数编译成完整的 AppSync API、DynamoDB 表结构、IAM Role 权限策略、Resolver 映射模板。Transformer 的强大在于它的“约定优于配置”model自动生成 CRUDL 操作和数据库表auth自动生成细粒度的 GraphQL 字段级权限控制searchable自动集成 OpenSearch Service。你不需要手动写 VTL 模板也不需要去控制台点几十次鼠标。这种分层让 Amplify 既能快速上手CLI 向导又能深度定制修改 Category 配置还能保持架构一致性Transformer 保证所有 Category 的部署逻辑统一。2.3 与同类方案的本质差异Firebase 是“全家桶”Supabase 是“开源替代”Amplify 是“AWS 生态翻译器”常有人问“Amplify 和 Firebase 比怎么样”这个问题本身就错了方向。Firebase 是 Google 提供的一套独立后端服务它的 Auth、Firestore、Storage 都是 Firebase 自己的托管服务和 GCP 的 IAM、Cloud Functions 是松耦合的。你用 Firebase本质上是在迁移到 Firebase 的生态。而 Amplify 是 AWS 的“翻译器”——它不提供自己的数据库或认证服务而是把 AWS 原生服务Cognito、DynamoDB、S3、AppSync的能力用前端友好的方式暴露出来。这意味着你的数据永远在你自己的 AWS 账户里权限策略完全遵循 AWS IAM你可以随时绕过 Amplify CLI直接用 AWS Console 或 Terraform 管理底层资源当业务增长需要精细化调优时比如 DynamoDB 的 On-Demand 改为 Provisioned加 Global Secondary Index你改的是真实的 CloudFormation 模板不是某个黑盒 SDK。再看 Supabase它是开源的 Firebase 替代品主打 PostgreSQL Realtime。它强在数据库灵活性和开源可控但弱在云服务整合深度——它没有原生的 CDN、边缘计算、AI 服务集成。Amplify 的优势恰恰在这里它背后是整个 AWS 云服务矩阵。当你需要给上传的图片自动加水印amplify add function创建一个 Lambda再用amplify update storage把 S3 事件触发器绑定上去三步搞定当你需要把用户行为日志实时推送到 Kinesis Data Streamsamplify add analytics就能生成对应管道。这不是功能堆砌而是把 AWS 数百项服务用一套统一的、面向应用开发者的语言重新组织。所以 Amplify 的定位很清晰它不是要取代专业云架构师而是让应用开发者能以“应用视角”而非“基础设施视角”来消费云能力。3. 核心功能实操拆解从零开始搭建一个带权限控制的 Todo 应用3.1 环境准备与项目初始化CLI 版本和 Node.js 的“隐形门槛”别跳过这一步。我踩过最大的坑就是用 Node.js 18.x Amplify CLI 10.x结果amplify init卡在“Initializing project”十分钟不动。查日志才发现是 CLI 10.x 对 Node.js 18 的 crypto 模块兼容有问题。最终解决方案是固定使用 Node.js 16.20.2LTS Amplify CLI 12.4.1。这不是随意选的而是 AWS 官方文档里明确标注的“推荐组合”。安装命令必须严格按顺序# 先卸载旧版 npm uninstall -g aws-amplify/cli # 清理 npm cache关键很多奇怪问题源于缓存 npm cache clean --force # 安装指定版本 npm install -g aws-amplify/cli12.4.1安装完后务必运行amplify configure进行一次全局配置。这里会要求你登录 AWS 控制台创建一个具有 AdministratorAccess 权限的 IAM 用户仅用于本地开发生产环境必须降权。CLI 会把这个用户的 Access Key ID 和 Secret Access Key 存在~/.aws/credentials里。注意这个用户是 Amplify CLI 的“操作员”不是应用的用户。它需要足够权限来创建 Cognito、AppSync、S3 等资源但你的前端应用代码里永远不应该硬编码这些密钥。初始化项目时amplify init会问你几个关键问题Enter a name for the project: 输入todo-app这个名称会成为 CloudFormation Stack 名称前缀Initialize the project with the above configuration?: 选 YesYour project has been successfully initialized and connected to the cloud!: 出现这行字才代表初始化成功。此时本地会多出amplify/目录里面是team-provider-info.json存储环境信息和cli-inputs.json存储 CLI 配置。这个目录必须加入.gitignore因为里面包含敏感的环境配置。3.2 添加身份认证AuthCognito 的“傻瓜式”配置与权限陷阱运行amplify add authCLI 会启动交互式向导。这里的选择直接影响后续所有功能的安全模型必须慎重Do you want to use the default authentication and security configuration?:不要选 Default。Default 会启用 Email/SMS 双因子但禁用 Social ProviderGoogle/Facebook而我们后面要做第三方登录。How do you want users to be able to sign in?: 选Username最通用兼容所有场景Do you want to configure advanced settings?:必须选 Yes。这才是关键。What attributes are required for signing up?: 至少勾选Email业务必需Do you want to enable user registration?: Yes允许新用户自助注册Do you want to enable social providers (Login with Facebook, Google, etc.)?: Yes为后续扩展留接口Do you want to enable MFA?: 选Optional开发阶段不用强制上线再改Do you want to enable email verification?: Yes防止垃圾注册向导结束后amplify/backend/auth/下会生成 Cognito User Pool 的 CloudFormation 模板。此时别急着push先打开amplify/backend/auth/resource-name/parameters.json检查两个关键参数userPoolGroupList: 如果为空数组[]说明没创建用户组。我们要支持“管理员”和“普通用户”所以手动添加userPoolGroupList: [admin, user]autoVerifiedAttributes: 确保是[email]这样用户注册后邮箱会自动验证不用点邮件链接。然后运行amplify push --yes。CLI 会编译模板、创建 CloudFormation Stack、等待所有资源就绪。整个过程约 3-5 分钟。成功后你会在 AWS 控制台的 Cognito 控制台里看到一个名为todo-app-env-random的 User Pool。此时前端就可以用Auth类了// 登录 await Auth.signIn(username, password); // 获取当前用户 const user await Auth.currentAuthenticatedUser(); // 获取用户属性包括自定义属性 const attributes await Auth.userAttributes(user);注意Auth.currentAuthenticatedUser()返回的是 Cognito 的原始用户对象包含username,attributes邮箱、电话等但不包含你业务系统里的用户 ID。你需要在用户首次登录后用Auth.updateUserAttributes()把业务 ID 写入custom:business_id属性或者在PreSignUpLambda Trigger 里自动创建。3.3 构建 GraphQL APISchema 设计、权限规则与 Resolver 调试运行amplify add api选择GraphQL然后Provide API name:todoApiChoose the default authorization type for the API: 选Amazon Cognito User Pool这是最安全的默认选项所有请求必须带有效 JWT TokenDo you want to configure advanced settings for the GraphQL API?:必须选 YesConfigure additional auth types?: Yes然后添加API key用于测试生产环境禁用Enable conflict detection?: Yes开启 Optimistic Concurrency Control避免多人编辑冲突向导完成后amplify/backend/api/todoApi/schema.graphql文件被创建。这是 Amplify 的“心脏”。我们来写一个带权限的 Todo Schematype Todo model auth( rules: [ # 所有已认证用户可以读取 { allow: authenticated, operations: [read] } # 创建者可以读写删 { allow: owner, ownerField: owner, operations: [create, read, update, delete] } # 管理员组可以读写删所有 { allow: groups, groups: [admin], operations: [read, update, delete] } ] ) { id: ID! title: String! description: String completed: Boolean! default(value: false) owner: String! auth(rules: [{ allow: owner }]) createdAt: AWSDateTime! updatedAt: AWSDateTime! }这个 Schema 看似简单但每行都有深意model: 告诉 Transformer 自动生成 DynamoDB 表、AppSync API、GraphQL 查询/变更/订阅。auth规则定义了三层权限。authenticated是最宽泛的只要登录了就能listTodosowner是基于owner字段的值做匹配确保用户只能操作自己的数据groups是基于 Cognito User Pool Group管理员可以管理所有数据。default(value: false): 为completed字段设默认值避免前端忘记传参导致空值。owner: String! auth(...): 这行是关键。auth在字段上意味着这个字段的值会被 Transformer 自动注入当前用户的 username来自 JWT Token 的cognito:username。你不需要在前端代码里手动赋值owner: Auth.currentAuthenticatedUser().usernameAmplify 会在 Resolver 层自动完成。写完 Schema运行amplify push。CLI 会生成并部署 AppSync API。部署成功后打开 AWS 控制台的 AppSync 控制台找到你的 API点击 “Queries” 标签页粘贴以下查询进行测试query ListTodos { listTodos { items { id title owner completed } } }在右上角的 “Authorization” 下拉框里选择 “Amazon Cognito User Pool”然后输入你的 Cognito User Pool ID 和 Client ID这些信息在amplify/team-provider-info.json里能找到。点击 “Run Query”你应该能看到空数组[]。现在用 Mutation 创建一个mutation CreateTodo { createTodo(input: {title: Learn Amplify, description: Its awesome!}) { id title owner } }执行后返回的owner字段应该自动填充为你当前登录用户的 username。这就是auth字段注入的威力——它把权限逻辑从应用代码里剥离下沉到 GraphQL 层既安全又不可绕过。3.4 集成文件存储StorageS3 的细粒度权限与预签名 URL 实战运行amplify add storage选择Content (Images, audio, video, etc.)然后Provide a friendly name for your resource:todoStorageProvide bucket name:todo-app-storage-envCLI 会自动补全Who should have access: 选Auth and guest users允许登录用户和未登录用户访问但权限不同What kind of access do you want for authenticated users?: 勾选create/update,read,delete登录用户可读写删What kind of access do you want for guest users?: 只勾选read游客只能读向导结束后amplify/backend/storage/todoStorage/parameters.json会生成。关键参数是authPolicyName和unAuthPolicyName它们分别定义了 Auth Role 和 UnAuth Role 的 IAM Policy。运行amplify push部署。部署完成后S3 Bucket 就创建好了。前端使用非常简单// 上传文件自动处理签名 await Storage.put(todos/${user.username}/image.jpg, file, { contentType: file.type, level: private // private: 只有上传者能访问protected: 所有登录用户能访问public: 所有人都能访问 }); // 下载文件自动获取预签名 URL const url await Storage.get(todos/${user.username}/image.jpg, { level: private, expires: 3600 // URL 1小时后过期 });这里的level: private是关键。它不是指文件物理存储位置而是指 Amplify 自动生成的 IAM Policy。对于private级别的文件Policy 会限制为s3:GetObject操作且Resource必须匹配arn:aws:s3:::todo-app-storage-env/private/${cognito-identity.amazonaws.com/id}/${key}。也就是说即使你知道了文件的 S3 URL没有有效的 Cognito Identity ID Token也无法访问。这就是 Amplify 把 S3 的复杂权限模型翻译成前端可理解的level参数的体现。实测中我们曾遇到一个问题上传大文件100MB时Storage.put()报错RequestEntityTooLarge。排查发现是 S3 的PutObjectAPI 限制。解决方案是启用分段上传Multipart Upload但 Amplify CLI 默认不开启。我们手动修改了amplify/backend/storage/todoStorage/parameters.json添加enableMultipartUpload: true, maxPartSize: 5242880然后amplify push重新部署问题解决。这再次证明Amplify 的“可定制性”不是口号而是真实存在的。4. 高阶实战与避坑指南从开发到上线的完整链路4.1 多环境管理dev/staging/prodGit 分支驱动的 CI/CD 自动化一个项目不可能只有一个环境。amplify init默认创建dev环境但你需要staging和prod。关键原则是环境隔离必须通过 Git 分支实现而不是手动修改配置。步骤如下在本地创建staging分支git checkout -b staging运行amplify env add输入环境名staging选择dev作为源环境这样会复制dev的所有 Category 配置运行amplify push --yesCLI 会为staging环境创建新的 CloudFormation Stack合并staging分支到main或master分支在main分支上运行amplify env add创建prod环境同样以staging为源运行amplify push --yes此时你的 Git 仓库里会有三个分支每个分支对应一个独立的 Amplify 环境。接下来是 CI/CD。Amplify Hosting 服务原生支持 Git 集成。在 Amplify 控制台连接你的 GitHub 仓库设置构建设置version: 1 frontend: phases: preBuild: commands: - npm ci build: commands: - npm run build artifacts: baseDirectory: build files: - **/* cache: paths: - node_modules/**/*然后为每个分支设置不同的构建环境变量staging分支AMPLIFY_ENVstagingprod分支AMPLIFY_ENVprod在src/aws-exports.js里Amplify 会根据AMPLIFY_ENV变量自动加载对应环境的配置。这样当你往staging分支 push 代码Amplify Hosting 会自动触发构建并部署到staging环境的 URL如https://staging.xxx.amplifyapp.com往prod分支 push则部署到生产 URL。整个过程无需人工干预真正实现了“代码即基础设施”。4.2 权限最小化实践如何把 AdministratorAccess 从开发账号里彻底移除前面提到amplify configure创建的 IAM 用户需要 AdministratorAccess但这只是开发阶段的权宜之计。上线前必须降权。方法是为每个 Amplify 环境创建专用的 IAM Role并授予最小必要权限。步骤如下在 AWS 控制台进入 IAM 服务创建一个新 Role选择AWS service-Amplify-Amplify Console注意不是 EC2 或 Lambda附加以下托管策略这是 Amplify 官方推荐的最小集AmplifyConsoleFullAccess用于 HostingAWSCloudFormationReadOnlyAccess用于读取 Stack 状态IAMReadOnlyAccess用于读取 IAM RoleS3ReadOnlyAccess用于读取 S3 配置然后为这个 Role 创建一个 Inline Policy精确授予它对当前 Amplify 环境资源的权限。例如对于todo-app-dev环境Inline Policy 如下{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ cognito-idp:CreateUserPool, cognito-idp:DescribeUserPool, cognito-idp:UpdateUserPool ], Resource: arn:aws:cognito-idp:us-east-1:123456789012:userpool/us-east-1_abc123def }, { Effect: Allow, Action: [ appsync:CreateGraphqlApi, appsync:UpdateGraphqlApi ], Resource: arn:aws:appsync:us-east-1:123456789012:apis/abc123def } ] }最后在amplify/team-provider-info.json里把dev环境的awscloudformation配置从原来的accessKeyId/secretAccessKey改为roleArn和roleSessionNamedev: { awscloudformation: { RoleArn: arn:aws:iam::123456789012:role/amplify-todo-app-dev-role, RoleSessionName: amplify-todo-app-dev-session } }运行amplify push测试。如果权限不足CLI 会明确报错告诉你缺少哪个 Action 和 Resource你可以据此精准补充 Inline Policy。这个过程可能需要迭代 3-5 次但一旦完成你的开发账号就彻底摆脱了 AdministratorAccess符合企业安全审计要求。4.3 常见问题速查表那些让你抓狂半小时的“小问题”问题现象根本原因解决方案实操心得amplify push报错Resource is not in the state stackUpdateCompleteCloudFormation Stack 正在被其他操作如控制台手动修改锁定运行amplify status查看当前状态如果显示UPDATE_IN_PROGRESS等待其完成或联系 AWS Support 取消挂起操作永远不要在 Amplify CLI 运行时手动去 AWS 控制台修改它管理的资源。这是最高频的死锁原因。前端调用Auth.signIn()成功但Auth.currentAuthenticatedUser()报错not authenticatedAmplify 的Auth类没有正确初始化或aws-exports.js加载顺序错误确保Amplify.configure(awsmobile)在Auth类使用前执行检查aws-exports.js是否被 Webpack 正确打包进 bundle在index.js或App.js的最顶部第一行代码就执行Amplify.configure()不要放在组件useEffect里。API.graphql()查询返回空数组但 AppSync 控制台里能看到数据GraphQL 查询的Authorization头没传或传了错误的 Token在浏览器 DevTools 的 Network 标签页查看 GraphQL 请求的 Headers确认authorization字段存在且是有效的 JWT Token用Auth.currentSession().getIdToken().getJwtToken()获取 Token不要用getAccessToken()后者用于调用 Lambda前者用于 AppSync。Storage.put()上传文件后Storage.get()返回 403 ForbiddenS3 Object 的 ACLAccess Control List被意外修改或level参数与 IAM Policy 不匹配运行amplify storage get查看当前 Storage 配置检查amplify/backend/storage/name/parameters.json里的authPolicyName永远用level: private或protected不要用public除非你真的想让全世界都能下载。amplify add function创建的 Lambda无法访问process.env.API_API_NAME_GRAPHQLAPIIDOUTPUT环境变量Amplify CLI 没有自动注入 API 环境变量因为 Function 和 API 不在同一 Category手动在amplify/backend/function/name/parameters.json里添加apiId: {Ref: apiApiNameGraphQLAPIId}然后amplify pushAmplify 的环境变量注入是“Category 内部”的跨 Category 必须手动关联。这是设计使然不是 Bug。4.4 性能优化与监控从 CloudWatch Logs 到前端性能埋点Amplify 本身不提供 APMApplication Performance Monitoring但它无缝集成了 AWS 的监控生态。关键监控点有三个CloudWatch Logs所有 Amplify 托管的服务Cognito、AppSync、Lambda都会自动将日志发送到 CloudWatch。在 CloudWatch 控制台创建一个 Log Insights 查询监控 AppSync 的错误率filter message like /ERROR/ | stats count(*) as errorCount by bin(5m) | sort errorCount descX-Ray 追踪为amplify add function创建的 Lambda 启用 X-Ray。在amplify/backend/function/name/function-parameters.json里设置tracing: Active。部署后所有 Lambda 调用都会生成 X-Ray 追踪你可以看到从 API Gateway 到 Lambda 到 DynamoDB 的完整耗时。前端性能埋点Amplify 的AnalyticsCategory 可以集成 Pinpoint。但更轻量的做法是用PerformanceObserver监控关键操作// 监控 Auth.signIn 耗时 const observer new PerformanceObserver((list) { for (const entry of list.getEntries()) { if (entry.name Auth.signIn) { console.log(Auth.signIn took:, entry.duration, ms); // 上报到自定义监控服务 reportToMonitoringService(Auth.signIn, entry.duration); } } }); observer.observe({entryTypes: [measure]}); // 在调用前打点 performance.mark(Auth.signIn-start); await Auth.signIn(username, password); performance.mark(Auth.signIn-end); performance.measure(Auth.signIn, Auth.signIn-start, Auth.signIn-end);这个方案不依赖任何第三方 SDK纯原生 API且能精确到毫秒级。我们在线上环境发现Auth.signIn()在某些低端安卓机上平均耗时 1200ms远超预期。进一步排查发现是 Cognito 的PreAuthenticationLambda Trigger 里做了耗时的外部 HTTP 调用。于是我们把那个调用移到了PostAuthentication阶段前端体验立刻提升。这就是监控的价值——它不解决技术问题但帮你准确定位问题在哪里。5. 实战总结与经验延伸当 Amplify 遇到真实业务的“不完美”我在项目上线后和团队开了一个复盘会。大家一致认为Amplify 最大的价值不是它省了多少代码而是它统一了前后端对“云能力”的认知语言。以前前端说“我要一个上传接口”后端回“给我 Swagger”DevOps 回“等我配好 S3 Policy”。现在前端说“我要amplify add storage”后端说“好我看看parameters.json里authPolicyName是什么”DevOps 说“我审核下生成的 CloudFormation 模板”。一句话就把所有人拉到了同一个频道。当然它也有局限。最大的局限是它假设你的业务模型能被 GraphQL 的model和auth规则覆盖。我们曾想做一个“共享待办”功能即一个 Todo 可以被多个用户共同编辑。auth(rules: [{ allow: owner }])只支持单 owner不支持多 owner。解决方案是放弃model改用amplify add api选择REST然后自己写 Lambda 处理复杂的权限逻辑。这并不违背 Amplify 的理念——它从不强迫你用某一种方式而是给你一个“最佳实践路径”当你偏离时它也能优雅地退回到“标准 AWS 开发模式”。另一个经验是永远把 Amplify CLI 当作“代码生成器”而不是“黑盒服务”。每次amplify push后我都会打开amplify/backend/目录看看生成的 CloudFormation 模板长什么样。这不仅能帮你理解底层原理更能让你在遇到问题时知道该去哪个服务的控制台排查。比如amplify add auth生成的模板里UserPoolClient的CallbackURLs是空的如果你要做 OAuth 登录就必须手动在模板里加上你的前端域名。这看起来是“额外工作”但正是这种“透明”让你对系统的掌控力更强。最后我想说Amplify 不是一个终点而是一个起点。它帮你快速跨越了“从零到一”的鸿沟但“从一到一百”的精细化运营依然需要你深入 AWS 的每一个服务。它简化了全栈开发但没有简化云架构的思考。真正的简化永远来自于对复杂性的深刻理解而不是对复杂性的逃避。