加载失败
讨论源自 Salesforce 面向 Heroku 的公告（An Update on Heroku），公告称平台会继续受支持但以维护和运维为主、不重点推出新功能。Heroku 本身是早期流行的 PaaS，曾以对 Rails 和 web 开发者友好的 DX 闻名，但近年出现 Supabase（开源后端即服务）、Vercel（前端/Serverless 部署平台）、以及 GCP 的 App Engine 与 Cloud Run 等替代方案。评论围绕三类主要争议展开：现有客户担心迁移成本与 DX 损失；对 Salesforce 的商业策略（停止新企业合同、Hyperforce/Falcon 等内部项目）与潜在出售持怀疑态度；以及技术上可行但费时的迁移路径（k8s/Argo、Terraform、自托管或 Cloud Run）的利弊权衡。理解这些背景能帮助把官方“not dead”声明放在产品衰退、企业策略与迁移成本的交汇处评估。
长期使用 Heroku 的团队强调平台带来的开发者体验（DX）和易用性仍然满足他们的需求，因此不会仓促迁移。评论指出全面迁移会消耗大量工程时间、提高工程成本，并且很可能带来比 Heroku 更差的 DX。许多团队选择在未来一年内逐步演练迁移方案以备不时之需，但更希望 Salesforce 改善沟通以避免被迫离开。
部分评论把官方声明中“以维护质量和运营为重而非推出新特性”的表述解读为止步不前的明确信号，认为这等于承认产品进入维护/遗留模式。评论具体列举竞争对手如 Supabase 与 Vercel 在功能和开发体验上已经超越 Heroku，有用户甚至表示多年未见实质性进步。基于这些迹象，他们预测 Heroku 会以“僵尸模式”存在，用户会逐步流失直到维护成本低于收入才彻底下线。
评论指出关键的商业信号——停止签新企业合同——会削弱 Heroku 的收入根基，因为企业合同通常支撑 PaaS/SaaS 的现金流。有人认为 Salesforce 本可把 Heroku 作为内部 PaaS 以支持自身上云，从而避免耗费资源在 Hyperforce/Falcon 之类的大型内部迁移项目上。也存在对被私募收购或被出售以回收现金的担忧，并有评论提醒大客户过度影响会使产品变得过度定制从而伤害广泛用户群。
有实际迁移经验的评论者把路线图分为云托管替代和自托管两类：部分团队从 Heroku 迁到 App Engine 再到 Cloud Run，认为在不考虑成本时 GCP 的开发体验与安全性令人满意。与此同时也有声音指出 Cloud Run 缺乏 Heroku 那种成熟的服务生态与一键绑定（addons），迁移会丢失现成集成。另一类建议是采用 k8s（Kubernetes）配合 Argo、Terraform 在自托管或廉价 VPS 上重建平台，这可以压低成本但需要显著工程投入；部分评论者还提到可以用 ChatGPT 辅助迁移设计。总体结论是技术上存在多种可行路径，但在时间、人力和 DX 方面存在明显权衡。
讨论中充斥讽刺与自嘲：有人用“如果有人写 X 没死，那 X 大概已经死了”来概括舆论，有人引用 Monty Python 的台词“pining for the fjords”嘲讽其濒死状态。这些调侃反映出对官方声明的不信任与群体性的悲观情绪。评论还把此次公告与之前更大的讨论串联，认为这是长期衰退的又一证据而非孤立事件。
PaaS（Platform-as-a-Service）: 一种托管应用平台，简化部署、运行和扩展应用的运维工作，Heroku 是此类服务的典型代表。
Cloud Run: Google Cloud 的 serverless 容器运行服务，按需运行容器实例，侧重容器化工作负载的无服务器部署。
App Engine: Google Cloud 的托管 PaaS 服务，提供受管运行环境以简化应用部署，属于 GCP 的传统 PaaS 选项。
k8s / Kubernetes: 一个流行的容器编排系统，用于管理容器化应用的调度、扩展、服务发现和故障恢复。
Argo: 面向 Kubernetes 的 GitOps 与 CI/CD 工具集合（例如 Argo CD、Argo Workflows），用于声明式部署与流水线自动化。
Terraform: 由 HashiCorp 提供的基础设施即代码工具，用于以声明式配置管理云资源和基础设施。
DX（Developer Experience）: 开发者体验，指开发流程、部署便利性、平台文档与工具链等对开发者效率和满意度的综合影响。