Heroku CLI 必须先安装并配置成功，VSCode 插件才能正常工作；需验证 heroku --version 和 heroku login，重启 VSCode，并确保项目根目录含正确 Procfile 和运行时文件（如 package.json 或 requirements.txt），部署失败时优先查看 OUTPUT 面板的 Heroku 日志。
Heroku CLI 必须先装好，插件才不是摆设
VSCode 里装了 Heroku 插件但点不动“Deploy to Heroku”，大概率是本地根本没装 heroku-cli。插件只是调用命令行工具的壳，不装 CLI 就像给没引擎的车按启动键。
常见错误现象：Command 'Heroku: Deploy to Heroku' resulted in an error (command 'heroku.deploy' not found) 或点击后无反应、弹出空终端。
- 去官网下载安装包（
https://devcenter.heroku.com/articles/heroku-cli），别只用npm install -g heroku—— Node 版常因权限或 PATH 问题找不到 - 装完在终端跑
heroku --version，有输出才算成功；再执行heroku login登录账号（会打开浏览器授权） - VSCode 需要重启才能识别新装的 CLI，或者用
Developer: Reload Window刷新
项目根目录必须有 Procfile 和 package.json（或对应运行时文件）
Heroku 不靠插件猜你用什么语言，它只看文件。没 Procfile，哪怕代码能本地跑，部署也会卡在 “No web processes running”。
使用场景：Node.js 项目最典型，但 Python、Ruby 等同理 —— 插件不会帮你生成这些文件，它只把现有结构推上去。
-
Procfile内容必须是纯文本，首行不能有空格或 BOM，例如：web: npm start（注意冒号后有空格） -
package.json里得有"scripts": { "start": "..." }，且命令要能监听$PORT（Heroku 动态分配端口，硬写3000必挂） - Python 项目需要
requirements.txt+Procfile（如web: gunicorn app:app），缺一不可
插件部署失败时，优先看 VSCode 输出面板里的 Heroku 标签页
图形界面点“Deploy”后静默失败？别急着重装插件。VSCode 底部状态栏点“OUTPUT”，再从下拉选中 Heroku，里面全是真实执行日志，比弹窗提示有用十倍。
容易踩的坑：插件把错误吞掉了一半，比如 git push rejected 实际是远程仓库未初始化，但界面上只显示“Deployment failed”。
- 典型报错：
! No app specified→ 没运行过heroku git:remote -a <your-app-name></your-app-name>绑定远程 -
error: src refspec master does not match any→ 本地 Git 还没提交过，先git add . && git commit -m "init" - 看到
remote: ! Push rejected, no Cedar-supported app detected→ 检查Procfile是否拼错名（大小写、扩展名）、是否在项目根目录
部署后打不开页面？重点查 heroku logs --tail 和端口监听逻辑
插件显示“Deploy succeeded”，但浏览器打开是 Application Error，说明进程启动失败，不是网络或配置问题。
性能影响不大，但调试路径很关键：Web 进程崩溃不会阻断部署流程，插件只管 git push 成功与否。
- 在终端运行
heroku logs --tail（确保已heroku git:remote绑定），实时看启动日志，90% 的崩溃在这里暴露，比如Error: listen EADDRINUSE: address already in use :::5000 - Node.js 必须用
process.env.PORT || 3000，且监听代码不能写死端口号；Express 示例：app.listen(process.env.PORT, () => {...}) - Python 的
gunicorn启动命令里不能带--bind 127.0.0.1:8000，Heroku 要求绑定0.0.0.0:$PORT，通常靠--bind $PORT自动替换
复杂点在于：部署动作本身很简单，但 Heroku 的运行约束（端口、进程类型、文件位置）和本地开发习惯冲突最多。插件省不掉这些细节检查，它只是个快捷按钮。
