Next.js中在/pages目录存放其他文件的影响及模块化架构可行性问询

你偏好的模块化目录结构如下：

/pages
--/somepage
----/index.tsx
----/_components
------/ComponentA.tsx
------/ComponentB.tsx

针对这种结构是否存在性能影响或其他不建议的原因，分析如下：

性能层面：无负面影响 #

• Next.js对pages目录的路由识别逻辑只会把符合约定的文件（如index.tsx、[id].tsx等）当作页面入口，带下划线前缀的_components目录会被路由机制忽略，不会被误解析为页面。
• 打包时，组件的加载逻辑和放在pages外的组件目录完全一致：Tree Shaking会自动剔除未使用的组件代码，代码分割也会按需加载页面所需组件，不会产生额外性能损耗。

不建议的潜在问题 #

• 组件复用障碍：如果后续这些组件需要被其他页面调用，当前的嵌套结构会导致跨目录引用路径冗长，不如将可复用组件统一放在根目录的components目录下便捷。
• 目录复杂度提升：随着项目页面增多，每个页面都嵌套自己的_components子目录，会让pages目录的层级深度和文件数量大幅增加，长期维护时定位文件的成本会上升。
• 团队协作冲突：如果团队已有统一的目录规范（比如约定公共组件放根目录、页面专属组件可选嵌套），这种个性化结构可能会让新成员上手困惑，增加沟通和对齐成本。

结论 #

如果这些组件仅为当前页面专属，且团队没有强制的目录规范，这种嵌套结构完全可以正常使用，不会有性能问题；但如果考虑组件复用性或团队协作效率，建议将可复用组件抽离到pages外的公共目录，页面专属组件可保留在当前页面的嵌套目录中。

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