Repository navigation
Releases: shuma12303/cf-deploy-panel
Release list
云端部署器 v1.1.1
云端部署器 v1.1.1
一次针对「部署可靠性」的专项修复：解决 面板提示部署成功、打开链接却打不开 / 打开是别人的网站 这一组问题。
由 数码解码 独立开发并维护。
一、这次到底修了什么
v1.1.0 及更早版本的部署链路，有三处与 Cloudflare 官方 wrangler 的实现不一致。三者叠加，会表现出三种典型症状：
| 你会看到的现象 | 真正的根因 |
|---|---|
xxx.pages.dev 返回 400 Bad Request |
静态资源哈希用了 SHA-256，而官方用的是 BLAKE3 |
| 部署完打开是空白 / Worker 完全不生效 | _worker.js 同时进了 manifest 和 _worker.bundle，而这两者互斥 |
| 打开链接看到的是别人的网站 | 项目名被 Cloudflare 自动改名（chongxin → chongxin-4k7），面板却仍用旧名字拼地址 |
v1.1.1 把这三条全部对齐官方实现，并在部署前后补上了多重校验 —— 宁可报错停下，也不再把失败包装成成功。
二、修复清单
1. 项目名被占用时，访问链接用错了名字（打开是别人的网站）
*.pages.dev 子域名是全球唯一的，不按账户隔离。
当你输入 chongxin 而该名字已被他人占用时，Cloudflare 不会报错，而是把项目建成 chongxin-4k7，真实名字放在返回对象的 name 字段里。旧版面板仍用你输入的 chongxin 拼访问地址，于是 https://chongxin.pages.dev/你的UUID 打开的是别人的项目——而部署其实已经成功了。
现在一律以 API 返回的真实项目名为准：upload-token、deployments、域名绑定、线上自检、返回给前端的链接全部同步，并在日志与结果里明确提示：
注意：项目名「chongxin」在 pages.dev 上已被占用，Cloudflare 实际分配为「chongxin-4k7」。
访问地址一律以「chongxin-4k7」为准。
2. 资源哈希算法对齐官方 BLAKE3
旧版用 SHA-256 计算 Pages 静态资源哈希，官方 wrangler 用的是：
blake3(base64(文件内容) + 扩展名).toString("hex").slice(0, 32)
算法不一致会导致 Cloudflare 无法命中资源，部署后的项目直接返回 400 Bad Request。
现已内置纯 JS 的 BLAKE3 实现（零外部依赖，不增加包体积），并与官方 blake3-wasm 做了逐字节比对，31 组固定用例全部一致。
3. _worker.js 不再进入 manifest
官方 wrangler 打包静态资源时会主动忽略 _worker.js——它由 _worker.bundle 承载，两者互斥（官方文档原文：Mutually exclusive with _worker.js. Cannot specify both）。
旧版把它同时写进 manifest 又提交 _worker.bundle，触发 Cloudflare 拒绝请求，这是「部署成功但项目 400 打不开」的直接原因。
现在按官方忽略清单过滤：
_worker.js _redirects _headers _routes.json
functions .DS_Store node_modules .git .wrangler
而 _headers / _redirects / _routes.json 改为在部署表单里单独上传。
4. 跨账户自定义域名被拦截（错误码 1014）
旧版读取全部账户的 Zone，Account 与 Zone 各自独立取第一个，从不校验归属。当域名 Zone 与 Pages 项目不在同一 Cloudflare 账户时，Cloudflare 会拒绝这个跨账户 CNAME，访问返回 403 / error code 1014，而部署日志却显示"部署完成"。
现在：
- Zone 列表带出所属账户（
accountId/accountName） - 域名下拉按所选账户过滤
- 部署前强制校验同账户，不匹配直接给出明确原因
5. CNAME 创建失败不再被静默吞掉
旧版 DNS 记录创建异常只记录一行"跳过"，界面照样显示成功。
现在会先查询是否已存在同名 CNAME：
- 记录已存在且指向正确 → 视为成功
- 指向不一致或确实创建失败 → 部署直接报错并说明原因
6. 不再「假成功」（部署落点硬校验）
旧版只把 Cloudflare 的部署状态写进日志，界面依旧显示"部署完成"。
现在只要出现以下任一情况，直接报错：
- 部署落在了预览环境（生产域名不会更新）
- Cloudflare 侧状态为
failure/failed/canceled
7. 新增部署后线上自检
部署完成后立刻回访一次 项目名.pages.dev，把真实 HTTP 状态码与页面字节数写进日志：
线上自检: https://xxx.pages.dev/ → HTTP 200，8499 字节
这是发现「日志说成功、打开却是旧页面」最快的手段。
8. 新建模式不再静默接管同名项目
旧版填了一个已存在的项目名，会悄悄 PATCH 该项目，并把它的 KV 绑定改成新的命名空间——等于破坏别人正在跑的项目。
现在新建模式撞到同名 Pages 项目或同名 Worker 脚本会直接报错，提示换名或改用「更新现有项目」模式。
9. 复用 KV 时 UUID 未同步（会导致链接打不开）
旧版复用已有 KV 时会跳过初始化，KV 里仍是旧 UUID，而面板却用新 UUID 拼访问链接——链接必然失效。
现在会把新 UUID 合并写回 KV 配置，同时保留用户已设置的其他字段。
10. 多账户时 Zone 跨账户过滤失效
账户下拉在"多于 1 个账户"时停在空值，导致按账户过滤 Zone 的逻辑拿不到账户、把所有账户的域名都列出来——跨账户防护形同虚设。
现在默认选中第一个账户（与后端默认一致），跨账户域名不会再出现在下拉里。
11. 资源数为 0 时也走完整资产流程
压缩包里只有 _worker.js 时，现在仍会完整执行 check-missing → upsert-hashes，与官方 wrangler 完全一致。
12. 空源码防护
_worker.js 为空文件时直接报错，不再提交一个空模块。
三、兼容性
- 向后兼容，无破坏性变更。除上述部署链路修复外，界面与操作方式与 v1.1.0 完全一致。
- 已部署的面板可继续使用；重新上传本版本部署包即可生效，无需修改域名、KV 或项目配置。
⚠️ v1.1.0 及更早版本部署出的 Pages 项目，若已处于 400 状态，需要用本版本重新部署一次才能恢复正常。
四、升级方式
方式一：面板内更新（推荐）
把本版本的 cf-deploy-panel-v1.1.1.zip 重新部署到原来的面板项目即可，覆盖部署，不影响已有配置。
方式二：wrangler
# 解压后进入目录
npx wrangler pages deploy . --project-name 你的面板项目名五、怎么验证这次真的部署成功了
部署完成后，按顺序看这三处：
1. 日志里找线上自检
线上自检: https://你的项目.pages.dev/ → HTTP 200，8499 字节
字节数对不上，说明没落对地方。
2. 访问 /api/version
curl https://你的面板.pages.dev/api/version返回 {"ok":true,"version":"v1.1.1"} 才算更新成功。
3. 验证部署出来的项目有没有 Worker 在跑
随便访问一个不存在的路径：
- 返回 404 → 纯静态站，Worker 没生效
- 返回项目内容 → Worker 正常
- 返回和首页完全相同的字节数 → 这是个 SPA 在兜底，你的 Worker 没进去
六、测试
| 套件 | 内容 | 结果 |
|---|---|---|
tests/validate.mjs |
静态校验、API 冒烟、部署防护、改名场景、前端登录记忆 | 69 项全通过 |
tests/hash-verify.cjs |
BLAKE3 与官方 blake3-wasm 逐字节对照 |
31 例全通过 |
tests/e2e-sim.mjs |
真实 zip 走完整上传链路 | 11 项断言全通过 |
七、完整更新日志
见 CHANGELOG.md。
v1.0.0 云端部署器首发版
云端部署器 —— Cloudflare Pages 一键部署面板（由 数码解码 独立开发并维护）
主要能力
- 一键把 Cloudflare Pages 项目部署到自己的账号（Global API Key 认证）
- 支持上传 zip 压缩包完整解压后部署（含 _worker.js 高级模式项目）
- 自定义项目名，自动生成合规名称
- 部署结果可点击直达 + 一键复制
- 本地部署历史记录
部署包说明
- 附件 cf-deploy-panel.zip 含 5 个平铺文件：index.html / styles.css / app.js / _worker.js / README.md
- 在 Cloudflare Pages 控制台直接上传该 zip 即可完成部署
© 数码解码 · 保留所有权利