Next.js 16.1.4 报 _self___NEXT_DATA___autoExport 未定义，核对 SWC 降级

next dev 启动正常，Pages Router 页面却在浏览器加载时报 ReferenceError: _self___NEXT_DATA___autoExport is not defined。若升级前正常，项目又配置了需要转换可选链或空值合并的旧浏览器目标，应先查看 SWC 生成代码，而不是给应用添加一个同名全局变量。

这一具体回归在 Next.js 16.1.4 得到确认，相同项目在 16.1.1 正常。16.1.6 已纳入 SWC 更新，并确认原场景恢复。这个版本节点用于识别历史故障；维护中的项目应采用符合框架支持与安全更新要求的版本，不必为了修一条旧回归长期固定历史补丁。

缺的是生成变量的正确作用域

源码中的空值合并可能写成：

const value = settings.direction ?? fallbackDirection;

settings 与 fallbackDirection 是应用已有变量，这里只展示需要降级的语法。面向不原生支持 ?? 的目标时，编译器会生成临时变量和条件表达式。正常情况下，声明与使用应处于相容作用域。

具体故障中，Next 客户端 AppContainer 使用了 _self___NEXT_DATA___autoExport，声明却被移进更深的 Component 函数。外层无法访问内层的局部声明，即使那个嵌套函数稍后运行，也不能补回外层绑定。

因此，不能把所有 __NEXT_DATA__ 相关错误解释成页面全局数据没有注入。错误名字里的 _self_... 是转换生成的临时变量，并不是让业务代码手动定义的公共 API。其他组件出现 _settings_direction is not defined 时，也应按实际生成语句核对，不能只按变量前缀推断同一根因。

Browserslist 能改变触发条件，也会改变支持范围

一个已确认触发的配置包含下面这样的旧目标：

{
  "browserslist": {
    "development": ["last 2 versions"],
    "production": ["chrome 72"]
  }
}

配置来自产品的真实支持要求时，应保留要求，用包含修复的构建器处理。删除 Browserslist 或改成较新目标，可能因为不再转换这些语法而避开错误，但同时会提高产物对浏览器的要求；不能只看自己的新浏览器恢复就直接上线。

也不应把 ?? 批量改成 ||。两者对 0、空字符串和 false 的含义不同，这会将编译故障变成业务默认值错误。手动覆盖某个平台的 @next/swc-* 为旧版，同样可能造成框架与编译器不匹配，不适合当作跨平台的正式升级方案。

核对整套 Next 构建依赖

16.1.6 的正式发布包含 SWC 54 回补。更新时保留包清单和锁文件，由框架正常解析匹配的原生 SWC 包，再重新启动开发环境、生成正式产物；不能只替换一个缓存文件。

验收使用原来的页面与真实目标配置，检查开发页面不再报初始化变量错误，再检查正式构建与预览。保留 null、undefined、0、空字符串等有意义输入，确认默认值行为没有因为临时改写表达式而改变。

相同转换回归可以同时影响不同打包入口，切换 Webpack 或 Turbopack 只能提供对照，不能预先认定某一方必然正常。若修复版本下仍出现未定义变量，应保留准确的生成代码与浏览器目标，重新判断是否是另一条转换或依赖问题。