TypeScript TS4053：导出类返回类型 cannot be named

源码能做类型检查，生成 .d.ts 时却报 TS4053，信息里提到 public method、external module 和 cannot be named。如果错误落在导出类的某个方法上，检查它推断出的返回类型，是否包含另一个模块没有公开的接口名。

2026 年的一条具体形态同时出现在 TypeScript 6 的预览版本与原生预览编译器中：底层模块导出一个类型别名，却没有导出别名指向的接口；公共类的方法返回该值或 undefined，声明生成需要描述这个返回契约时失败。这不等于所有类型别名都不能用，也不能把 TS4053 一概当成切换原生编译器带来的回归。

看推断结果，不只看参数上的公开别名

下面是用于说明名称关系的两个文件。Base 有一个示例字段，实际项目应保留自己的完整定义：

// lib.ts
interface Base {
  id: string;
}
export type ExportBase = Base;

// main.ts
import type { ExportBase } from './lib.js';

export class Reader {
  maybe(value: ExportBase, enabled: boolean) {
    if (enabled) return value;
    return undefined;
  }
}

参数写了可导入的 ExportBase，并不保证声明生成器会在所有推断位置保留这个别名。返回值推断可能转向底层 Base；这个名字没有导出，跨模块生成公共声明时就无法按该名称引用。

这里需要的是启用了声明生成的实际包构建。仅在不检查声明契约的配置下通过类型检查，或把类留在模块内部，都不能验证公开 .d.ts 是否能生成。--noEmit 本身不等于关闭所有声明相关诊断，还要看项目配置。泛型约束、增加一层对象包装也可能改变推断形态，不能把某个包装恰好通过检查当成所有版本的稳定解决方式。

自有类型模块，明确导出公共返回契约

如果这两个模块都由项目维护，可以把实际属于公共 API 的接口导出，并在方法边界写出返回类型：

// lib.ts
export interface Base {
  id: string;
}
export type ExportBase = Base;

// main.ts
import type { Base } from './lib.js';

export class Reader {
  maybe(value: Base, enabled: boolean): Base | undefined {
    if (enabled) return value;
    return undefined;
  }
}

这样返回类型中的名字本身就是模块的公开成员。原有 ExportBase 可以为现有消费者保留，不必为了让声明生成成功删掉旧入口。是否公开 Base 应按包的 API 设计决定；接口内部若还引用未导出的类型，也要继续检查整条公开类型关系。

如果类型来自第三方包，不能直接把上例当作修改 node_modules 的办法。先查它是否已有可公开引用的等价接口或返回类型，并为自己的方法显式写出准确契约；没有合适类型时，需要修正上游类型出口，或在自己维护的边界定义忠于真实数据的公共结构。不要用 any、空类型或不真实的断言让声明勉强输出。

不要为了消掉 undefined 改掉业务分支

把方法改成每个分支都返回参数，可能改变推断，也会改变原来的运行时行为。若关闭条件本来应返回 undefined，必须保留这个语义。复制类型别名后再随意拼接一个交叉类型，同样可能改变可赋值关系，不能仅凭编译通过采用。

用原来的包构建入口重新生成声明，查看 Reader.maybe 的返回类型是否准确保留空值分支、引用是否来自真正导出的模块成员。再从包入口建立一个消费侧检查，确认有效值与 undefined 都按契约处理，没有意外暴露内部类型或改变条件导出路径。

这些处理针对公共类型名称的可表达性；不能仅靠切换编译器版本保证所有推断形态都可生成声明。这里不要求关闭 declaration、严格检查或整个声明发布步骤；这些开关只会让安装者拿不到原本需要的类型契约。