Windows下cpanm安装Perl依赖报Bareword not allowed错误

本地搭建Perl项目运行环境时，执行依赖安装命令触发cpanfile解析报错，具体场景与已知信息如下：

• 已完成Strawberry Perl安装，团队无人员熟悉该项目的本地原生运行方法，过往开发依赖克隆AWS实例虚拟机开展，虚拟机与本地的文件同步流程繁琐
• 项目根目录cpanfile首行内容为Docker/cpanfile;，同文件内声明了Time::Piece、File::Slurp两个依赖
• 项目其余所有依赖模块均声明在Docker/目录下的cpanfile文件中
• 在Git Bash中执行cpanm --installdeps命令时安装失败，报错信息显示cpanfile解析失败：第1行启用strict subs规则时不允许使用裸字"Docker"、裸字"cpanfile"，提示可查看对应build.log获取详情
• 项目内Docker相关文件已多年未维护，不存在可用Docker镜像，无法通过容器化方式部署运行
• 核心疑问：该错误是否需要关闭某类严格校验规则，或是调整相关配置解决

不需要关闭任何严格校验规则，该报错本质是根目录cpanfile存在语法错误，和严格模式本身无关。

cpanfile是基于Perl DSL实现的依赖配置文件，解析时默认启用strict语法校验，你看到的首行Docker/cpanfile;是当初写配置的人试图嵌套引入Docker目录下的依赖文件，但使用了完全不符合规范的写法——Perl会把这行里的Docker、cpanfile识别为未声明的裸式子程序，自然会触发strict subs的报错。旧AWS虚拟机环境能兼容这种错误写法，大概率是预装了自定义解析插件、或使用了带特殊容错逻辑的旧版cpanm，本地标准环境不需要为了兼容错误写法调整全局Perl配置。

按以下步骤处理即可解决问题：

1. 打开项目根目录的cpanfile，直接删除首行的错误内容Docker/cpanfile;，保留文件内已正确声明的两个依赖：

requires 'Time::Piece';
requires 'File::Slurp';

2. 打开Docker/目录下的cpanfile，将其中所有requires开头的依赖声明行，全部复制粘贴到根目录cpanfile的末尾
3. 回到项目根目录，重新执行cpanm --installdeps . 即可正常完成全量依赖安装

注意：不要尝试用do 'Docker/cpanfile'之类的Perl代码动态加载Docker目录下的旧配置文件，该文件是为多年前废弃的Docker构建流程编写的，直接合并依赖声明是最稳妥的方案，不会引入旧构建流程里的冗余逻辑。
如果合并依赖后仍有模块安装失败，直接打开报错提示的build.log查看具体失败原因，Strawberry Perl自带Windows环境所需的常用编译工具链，绝大多数CPAN模块可直接编译安装，少数编译失败的模块可单独针对性处理。

内容的提问来源于stack exchange，提问作者Josh Dredge