type
status
date
slug
summary
tags
category
icon
password
❓
对了，你读完可能还是不知道怎么做？我发现最简单的方法就是把这个文章丢给cursor之类Ai，让它读了，它就知道怎么做。如果你的Ai读不了链接，那么你可以将文章转换成PDF给它。
方法：一键将网页转换成PDF>

问题的发现

昨天（2025年10月8日），notionNext突然无法部署，一直报错。
notion image
各种报错，显示为code 530
因为我当时正好在改各种样式，我以为是自己的问题。恢复git……各种搞了十几个小时，还得Ai争辩了半天——我认为不可能是notion或notionNext的问题，肯定是Ai给我改代码改坏了……
notion image
我恢复了几次git，重启了ECS，清空了vercel的缓存……
最后发现，真的是官方出了问题
notion image
notionNext的开发者tangly1024给出一个方案：
NotionNext帮助手册NotionNext帮助手册API_BASE_URL | NotionNext帮助手册
API_BASE_URL | NotionNext帮助手册

API_BASE_URL | NotionNext帮助手册

Notion开源、免费、快速建站

NotionNext帮助手册NotionNext帮助手册
社区的解决方案指出，我们可以通过设置一个名为 API_BASE_URL 的环境变量，将 API 请求从不稳定的官方地址 www.notion.so 重定向到我们自己的、更稳定的个性化 Notion 域名。
我的个性化域名是 https://du*****e.notion.site，因此我需要在项目中配置一个新的 API 端点：https://du*****e.notion.site/api/v3。
按官方说明，最好是升级到notionNext新版本——但我做了不少定制化的事情，所以不想升级，然后按说明人开始了尝试。

步骤 1：修改 blog.config.js

首先，我让代码能够识别这个新的环境变量。

步骤 2：在 GitHub Actions 中设置 Secret

然后，我在 GitHub 仓库的 Settings -> Secrets and variables -> Actions 中，添加了一个名为 API_BASE_URL 的 Secret，并填入我的新地址。
[此处可以插入 GitHub 设置 Secret 的截图]

步骤 3：修改工作流文件

最后，我在 .github/workflows/deploy-to-domestic.yml 文件中，将这个 Secret 注入到构建环境中。
我满怀信心地提交了代码，等待着流水线变绿。然而，现实给了我沉重一击——构建依然失败，错误还是那个熟悉的 530。日志显示，请求依然顽固地发往了旧的 notion.so 地址。

漫长但严谨的排错之旅

一次失败并不可怕。这标志着一次深度调试的开始。

怀疑 1：环境变量传递链问题？

我的第一反应是，API_BASE_URL 变量可能在 npm 脚本的执行过程中“丢失”了。
  • 尝试 A：我尝试使用 KEY=VALUE command 的方式，在执行命令时直接注入变量。
      • 结果：失败。
  • 尝试 B：我怀疑是 npm run 或者脚本中的 cross-env 工具搞的鬼。我决定绕过它们，直接在工作流中执行 npm run export 背后的命令。
      • （注意：这里需要用 npx，否则会因为找不到 next 命令而报 command not found 错误。）
      结果：依然失败！错误还是 530，请求地址还是旧的！
[此处可以插入 GitHub Actions 多次失败的日志截图]
至此，我几乎可以断定：问题不在于环境变量的传递，而在于应用程序本身！ 我们把“钥匙”准备好了，但“锁”似乎从未打算使用它。

怀疑 2：代码压根没用这个变量？

既然所有环境配置的努力都宣告失败，唯一的可能就是代码实现上存在问题。我把目光投向了项目源码。
通过在项目中搜索 notion-client 这个关键词，我很快定位到了一个关键文件：lib/notion/getNotionAPI.js。它的作用正是初始化与 Notion 通信的 API 客户端。

最终的解决方案：直击代码根源

打开 lib/notion/getNotionAPI.js，真相大白。
修改前的代码是这样的：
问题一目了然：在初始化 NotionAPI 客户端时，代码只传递了用户、令牌等信息，完全没有传递我们辛辛苦苦配置的 API_BASE_URL！
notion-client 这个库需要一个名为 apiBaseUrl 的参数来指定 API 地址。由于代码中没有提供，它就只能一直使用自己内部硬编码的默认地址。
最终的修复方案，只需要加一行代码：
这行代码像一座桥梁，终于将我们在 blog.config.js 中读取的环境变量，与实际的 API 客户端连接了起来。
提交这次修改后，GitHub Actions 的流水线终于亮起了久违的绿色。
notion image

总结

这次 530 错误的解决过程，是一次非常经典的、从环境配置深入到应用层代码的调试之旅。它告诉我们：
  1. 官方文档并非万能：它提供了正确的方向，但可能没有覆盖到特定版本或特定场景下的代码实现细节。
  1. 系统性排错至关重要：当遇到看似是环境的问题时，如果多次尝试均失败，要敢于怀疑问题出在代码本身。通过“假设-验证-排除”的循环，才能一步步逼近问题的根源。
  1. 深入源码是终极武器：当所有外部手段都失效时，直接阅读源码是解决问题的最可靠方法。
经过这一番折腾，我的博客终于恢复了自动构建。希望这篇文章能帮助遇到同样问题的你，少走一些弯路，更快地定位并解决问题。