请问如下方式创建全局const变量是否正确？

这个实现有一定合理性，但也存在几个需要留意的细节，咱们来逐一拆解：

你的实现的可取之处 #

• 借助Object.defineProperty定义的全局db，默认是不可枚举、不可修改、不可配置的（该方法的configurable、enumerable、writable默认值都是false），完美契合你想要的「全局const」需求，能有效避免这个数据库连接被意外覆盖或篡改。
• 全局挂载单例数据库连接，确实能避免不同模块重复创建连接，减少资源消耗。

需要注意的潜在问题 #

• 全局命名冲突风险：db这个名字太通用了，要是后续引入的第三方库或者自己的其他代码也用到了同名全局变量，很容易出现难以排查的冲突问题。
• 测试难度提升：一旦代码依赖全局的db，写单元测试时很难模拟或替换这个连接，测试的隔离性会大打折扣。
• 异步初始化隐患：sqlite3.Database的构造函数是异步打开数据库的，你的代码直接赋值给全局变量后，其他模块如果在连接建立完成前就调用db，可能会触发未就绪的错误。

更推荐的替代方案 #

Node.js里管理共享资源的标准做法是通过模块导出单例，而非全局变量，比如创建一个db.js文件：

const sqlite3 = require('sqlite3');
const db = new sqlite3.Database(__dirname + '/database.db', (err) => {
  if (err) {
    console.error('数据库连接失败:', err.message);
    process.exit(1); // 连接失败时可以选择退出进程
  } else {
    console.log('数据库连接成功');
  }
});

module.exports = db;

之后其他模块需要使用数据库时，直接引入即可：

const db = require('./db.js');
// 后续正常调用db的方法

这种方式的好处：

• 完全避免全局污染，变量作用域仅限于模块内部，不用担心命名冲突。
• 测试时可以轻松mock这个模块，替换为测试专用的数据库连接，提升测试灵活性。
• 可以更清晰地处理连接初始化的异步逻辑，比如在回调里确认连接成功后再让业务代码执行。

若坚持使用全局变量的优化建议 #

如果因为项目规模或其他原因一定要用全局变量，可以做以下优化：

• 给变量名加独特前缀，比如__MY_APP_GLOBAL_DB__，大幅降低冲突概率。
• 补充异步初始化的回调处理，确保连接就绪后再被使用：

const sqlite3 = require('sqlite3');
Object.defineProperty(global, "__MY_APP_GLOBAL_DB__", { 
  value: new sqlite3.Database(__dirname + '/database.db', (err) => {
    if (err) {
      console.error('全局数据库连接失败:', err);
      process.exit(1);
    }
    console.log('全局数据库已就绪');
  }) 
});

总结来说：小型项目里你的实现勉强能用，但从长期维护、可测试性的角度看，模块导出单例的方式是更优选择。

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