Vite 同时开启 SSR 和库构建却说没有入口：显式设置 lib.entry

配置里已经写了顶层 input，构建却报 Either "build.lib.entry" or the top-level "input" option is required when "build.lib" is set.。如果同时启用了 build.ssr: true 和 build.lib，检查入口是否只留在客户端环境。

Vite 8.3.4 有这组具体条件：移除 build.ssr 后能构建，加回后报缺入口。8.3.5 的正式实现中，SSR 环境也没有像客户端一样继承顶层 input，库入口检查仍要求解析后的 lib.entry 存在，因此不能假定只升一个补丁就自动恢复。

入口文件存在，也可能没进入当前环境

先保留完整配置、实际执行的构建命令和报错。确认正在构建的是服务端库，而不是普通浏览器库或 HTML 页面。根配置中的 input、环境中的 input、build.rolldownOptions.input 和 build.lib.entry 属于不同配置位置，不应因为字符串相同就把它们当作总会互相继承。

如果框架或插件创建了独立 SSR 环境，还要看最终交给该环境的配置。文件确实在磁盘上，只能排除“文件不存在”，不能排除“该环境根本没有收到入口”。

将库入口明确放到 lib.entry

下面是单入口服务端库的最小配置形状，路径和输出格式仅作示例：

import { defineConfig } from 'vite';

export default defineConfig({
  build: {
    ssr: true,
    lib: {
      entry: 'src/server.ts',
      formats: ['es'],
      fileName: 'server',
    },
  },
});

把实际库入口写进现有 build.lib.entry，保留原来的外部依赖、插件、目标平台和输出约定。多入口库应保留原来的入口映射，不能为了通过校验缩减成一个随意选的文件。

示例用 es 说明一种输出要求，不表示所有 SSR 库都必须改成 ESM。原消费者要求 CommonJS 时，应按它的加载方式保留格式。也不要为了让入口被继承而关闭 SSR，那会改变服务端构建的处理条件。

从生成的入口检查消费方式

通过原来的构建入口重新生成产物，检查预期导出是否位于正确输出文件、外部依赖是否仍按约定保留，并在实际服务端消费方式下加载。构建退出 0 之后，还要核对包的 exports、文件扩展名和模块格式，避免生成成功但消费者读到另一份文件。

若单独设置 lib.entry 仍报同样错误，继续检查插件是否覆盖了库配置、构建是否从另一个工作目录启动，以及环境专用配置是否重写入口。不要把旧产物复制进输出目录当成新构建通过。撤回时恢复对应配置与输出，保留报错时的实际环境信息，便于核对后续正式修正。