pulumi up 卡在“performing changes…”通常是云厂商轮询导致的假性卡死，应加 --logtostderr -v=3 查看日志，对长耗时资源设 timeouts，ci 中改用 preview + up --yes 组合；敏感值须用 pulumi.tosecret() 或 secrets manager 拉取；s3 acl 不可更新，需 replaceonchanges 或改用可更新字段。
为什么 pulumi up 一直卡在 “Performing changes…” 却没报错
这是 Pulumi 最常被误判为“卡死”的场景，实际多数是云 provider 正在轮询资源状态（比如 AWS 创建 RDS 实例要等十几分钟），而 CLI 默认不输出中间日志。
- 加
--logtostderr -v=3查看底层 HTTP 请求和轮询细节，确认是否真卡住还是单纯慢 - 对耗时长的资源（如
aws.rds.Cluster、aws.ec2.Vpc），用timeouts参数显式设超时，避免无限等待：timeouts: { create: "60m" } - 别在 CI 环境里直接跑
pulumi up—— 缺少交互确认 + 日志截断容易误判；改用pulumi preview --diff+pulumi up --yes组合
Go SDK 中怎么安全传入敏感值（比如数据库密码）
直接写死 password: "my-secret" 会进 Git 和 state 文件，Pulumi 不会自动加密它。
- 必须用
pulumi.secret()包裹原始值：password: pulumi.String("raw-pass").ApplyT(func(s string) string { return s }).(pulumi.StringOutput).ApplyT(pulumi.StringSecret)，但更推荐用pulumi.ToSecret()（v3.70+） - 环境变量注入时，别用
os.Getenv()直接拼字符串 —— 那样值仍会出现在 plan 输出里；改用pulumi.Config.GetSecret()或pulumi.StackReference.GetOutput() - 如果用外部密钥管理服务（如 AWS Secrets Manager），用
aws.secretsmanager.GetSecretVersion拉取，返回值天然是 secret 类型
本地开发时 pulumi destroy 报 “no stack selected”
不是命令写错了，而是当前目录没绑定到任何 stack，Pulumi 找不到操作目标。
- 先运行
pulumi stack ls看有没有列出 stack；没有就说明还没初始化过 - 用
pulumi stack init dev --secrets-provider=passphrase创建新 stack（注意：Go 项目必须先go mod init，否则pulumi login会失败） - 如果之前用过
pulumi login --local，现在切到云端后记得pulumi logout再login，否则stack ls会查空列表
为什么 Go 代码里修改了 aws.s3.Bucket 的 acl 字段，pulumi up 却不生效
因为 S3 Bucket 的 acl 是“创建时一次性参数”，AWS API 不允许更新。Pulumi 检测到变更后，默认策略是替换资源（destroy + create），但如果你没开 replaceOnChanges 或没处理依赖，就会静默跳过。
立即学习“go语言免费学习笔记（深入）”；
- 显式声明替换行为：
replaceOnChanges: []string{"acl"} - 检查依赖链：如果这个 bucket 被其他资源（如
aws.s3.BucketPolicy）引用，替换前必须先删 policy，否则会失败 - 更稳妥的做法是弃用
acl，改用aws.s3.BucketOwnershipControls+aws.s3.BucketPublicAccessBlock，它们支持更新
真正麻烦的从来不是写几行 Go 代码，而是搞清哪个字段触发 replace、哪个字段被 provider 忽略、以及 secret 到底流到了哪一层日志里。
