先记住这个答案
当构建工具能处理资源导入但 TypeScript 缺少类型时，可以在被项目读取的脚本式声明文件中用 declare module ".png" 或 ".module.css" 描述导出形状。图片可能导出 URL、带尺寸对象或组件，CSS Modules 通常导出类名映射，必须与实际加载规则一致。通配声明只解决类型识别，不安装加载器、不校验资源文件一定存在，也不检查每个 CSS 类名的拼写。项目已经由框架提供资源类型时应优先使用现有契约，避免重复声明造成冲突或错误承诺。
- 资源类型由实际加载规则决定，不能一律写成 string
- 通配声明解决模块类型，构建器仍负责真实资源
- 需要检查文件与类名时采用更精确的生成声明或构建检查
同一个扩展名可能对应不同导出规则
普通 PNG 导入在某些工具中是 URL，在另一些框架中可能是包含尺寸和地址的对象。SVG 还可能通过特定查询后缀或插件转换为组件。因此遇到类型错误时，先查看当前框架已经提供的声明和实际构建结果，不要直接抄最宽泛的补丁。
下面声明两类约定明确的资源。css 模块的映射只承诺读取类名得到字符串，不知道文件里究竟有哪些键；它方便迁移，但把不存在的 className 写进去时未必会报错。通配规则也可能让一个拼错文件名的导入在类型层通过。
// types/assets.d.ts：保持为脚本式声明文件
declare module '*.png' {
const url: string;
export default url;
}
declare module '*.module.css' {
const classes: Readonly<Record<string, string>>;
export default classes;
}该声明没有读取图片和 CSS 文件，只描述匹配说明符的默认导出。若项目启用 noUncheckedIndexedAccess，任意类名读取还可能包含 undefined；需要精确类名检查时应生成具体键的声明。
类型通过后仍然可能在构建时失败
缺少对应加载器、资源路径不存在或部署公共路径错误，都不会被上面的声明自动修复。只导入副作用的样式语句又有自己的检查行为；启用 noUncheckedSideEffectImports 可以让未解析的副作用导入暴露问题，但宽通配声明仍不证明文件存在。
应分别确认类型解析、构建转换和页面资源请求。浏览器中出现空白图片时，还可能是生成 URL、资源发布或网络路径的问题。不断扩大 declare module 的匹配范围只会让编译器看不到更多错误，不能替代对实际资源链路的验证。
更精确的声明适合约束真实导出集合
CSS Modules 可以由工具生成包含实际类名的声明文件，修改样式后同步更新，拼错键就能被发现。自定义扩展名还可结合 TypeScript 支持的任意扩展名声明规则，例如为 app.css 配置 app.d.css.ts，但需要对应选项和正确模块解析环境。
生成声明也需要维护生命周期：删除资源时删除旧类型，修改类名时更新产物，并在干净消费环境里验证。否则旧声明会继续承诺已经消失的资源。不要为方便而把所有未知扩展名声明为 any，这会把路径拼写和导出使用错误一起隐藏。
容易答错的地方
- 写 declare module 就等于给 webpack 安装了加载器
- 声明只参与 TypeScript 类型解析，实际文件转换仍由构建器负责；必须独立验证构建配置和最终资源请求是否正常。
- Record<string, string> 能检查所有 CSS 类名拼写
- 它接受任意字符串键，不知道真实样式文件的类名集合；需要准确提示时应使用按文件生成的具体键类型。
面试官还会怎么问？
框架已经提供图片类型还需要补通配声明吗？
通常不需要。先检查现有类型是否进入当前项目配置，再核对导入形式；重复声明可能造成默认导出冲突，也可能掩盖框架真实返回对象。
SVG 应该声明为组件还是字符串？
取决于当前插件与导入规则。若某个查询后缀才返回组件，应让声明区分这些说明符，不能对所有 SVG 导入一概承诺相同形状。
为什么拼错图片路径也能类型检查通过？
通配环境模块按说明符模式提供类型，不必读取对应资源文件。真实文件存在性要由构建器或额外资源检查确认，不能仅依靠通配声明。
参考资料
- TypeScript：Pattern ambient modules
- TypeScript：allowArbitraryExtensions
- TypeScript：noUncheckedSideEffectImports
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。