NextJS中用.js存私密变量替代.env是否安全？二者底层差异？

为什么用dotenv会报错？ #

NextJS的页面组件会被编译打包到浏览器环境，而dotenv依赖Node.js的fs模块读取本地.env文件——浏览器环境根本没有fs模块，所以编译时会出现模块找不到的错误。而且NextJS本身已经内置了环境变量支持，完全不需要手动调用dotenv.config()。

你的解决方案安全吗？ #

用env-config.js存私密变量并加入.gitignore的方式是安全的，但有前提：

• 如果你把这个JS文件只在服务端代码（比如pages/api/下的接口、getServerSideProps/getStaticProps这类服务端渲染逻辑）里引入，变量不会被打包到客户端，不会泄露。
• 但如果不小心在客户端组件里import这个文件，所有变量都会被嵌入到前端打包后的代码中，任何人都能通过查看网页源码拿到这些变量——如果是敏感的API密钥之类的，绝对不能这么做。

.env与.js存储私密变量的底层差异 #

1. 加载机制不同 #

• .env：纯文本键值对文件，依赖Node.js的文件读取能力加载，NextJS会自动处理.env文件，把变量注入到process.env中，不需要手动写加载逻辑。
• .js：是JavaScript模块，通过import/require直接加载到内存，变量以JS对象的形式存在，不需要额外的文件读取操作。

2. 环境隔离能力不同 #

• .env：NextJS原生支持多环境区分（比如.env.development、.env.production），自动加载对应环境的变量；而且非NEXT_PUBLIC_前缀的变量默认只在服务端可见，不会被打包到客户端，天然做了隔离。
• .js：没有自动的环境区分，需要自己写逻辑判断process.env.NODE_ENV来导出对应环境的变量；如果在客户端import，变量会直接被打包到前端代码，完全没有隔离。

3. 规范与工具兼容性不同 #

• .env：遵循通用的环境变量规范，团队协作时更容易统一，Docker、CI/CD等工具都原生支持读取.env文件，扩展性更强。
• .js：灵活性高，可以写逻辑处理变量，但缺乏统一规范，容易出现变量管理混乱，而且复杂逻辑会增加维护成本。

推荐的NextJS环境变量用法 #

• 服务端专用变量：直接写在.env里，不用加NEXT_PUBLIC_前缀，比如EDITION_DROP_ADDRESS=xxx，在服务端代码里直接用process.env.EDITION_DROP_ADDRESS即可。
• 客户端需要的变量：在.env里加NEXT_PUBLIC_前缀，比如NEXT_PUBLIC_EDITION_DROP_ADDRESS=xxx，客户端组件里直接用process.env.NEXT_PUBLIC_EDITION_DROP_ADDRESS，NextJS会自动把它打包到客户端。

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