迁移pdf-lib封装代码至共享项目后调用失败，是转译器问题吗？

问题背景 #

• 基于pdf-lib封装的TypeScript自动化测试代码，在原项目运行正常，迁移到共享项目后出现报错
• PDFDict类的get方法内部调用this.dict.get(key)（this.dict为JavaScript Map对象），原项目返回FlateDecode，共享项目返回undefined
• 调试发现：原项目中Map的键与传入的key均为PDFName类型；共享项目中Map的键为PDFName2类型，传入的key为PDFName3类型

核心原因分析 #

Map对象的键匹配依赖**严格相等（===）**规则，对于引用类型而言，只有两个对象是同一引用时才会匹配。如果PDFName、PDFName2、PDFName3是不同的类实例（哪怕结构、功能完全一致），Map会将它们判定为不同的键，直接导致get方法返回undefined。

这种类型重复的情况，大概率是转译器（如Babel、TypeScript Compiler）或模块打包工具（如Webpack、Rollup）引发的问题，常见诱因包括：

• 共享项目与原项目的转译配置存在差异，导致pdf-lib中的PDFName类被重复转译，生成了不同的构造函数实例
• 模块解析策略问题，比如pdf-lib被重复安装多次，或者在不同模块上下文被加载，使得类的定义被重复初始化

结论与排查方向 #

这确实很可能是转译/打包工具的问题，建议从以下方向排查：

• 对比共享项目与原项目的tsconfig.json、Babel配置，重点检查模块输出、类型转换相关的配置项
• 确认pdf-lib在两个项目中是否为同一版本，且没有被重复安装（可查看node_modules目录和package-lock.json/yarn.lock文件）
• 检查打包工具的模块缓存、tree-shaking等配置，排查是否存在导致PDFName类被多次实例化的情况

内容的提问来源于stack exchange，提问作者Kevin McDowell