拓冰网站定制 
数据库后端【免费下载链接】objection.jsAn SQL-friendly ORM for Node.js项目地址https://gitcode.com/gh_mirrors/ob/objection.js点击查看免费下载在数据库中使用snake_case命名first_name、parent_id而在 JavaScript 代码中使用camelCase命名firstName、parentId是 Node.js 后端项目最常见的命名习惯之一。objection.js 针对这一需求提供了两套官方解决方案knex 层的knexSnakeCaseMappers和 objection 层的snakeCaseMappers。本文将基于 snake-case-to-camel-case-conversion 配方文档结合仓库源码lib/utils/identifierMapping.js、lib/model/Model.js与集成测试深入讲解这两种方案的原理、配置、选项与选型建议帮助你根据自己的项目结构选择正确的转换方式。为什么需要 snake_case / camelCase 转换关系型数据库中的列名通常遵循snake_case约定如first_name而 JavaScript/TypeScript 社区则普遍采用camelCase风格如firstName。如果让代码与数据库直接使用同一套命名会产生两难要么代码中出现大量下划线命名的属性要么数据库中出现驼峰命名的列两者都破坏各自生态的惯例。objection.js 提供的核心价值在于转换是自动的、可配置的你不需要在每个模型里手写$parseDatabaseJson/$formatDatabaseJson来做字段映射。官方给出了两种截然不同的实现位置它们的覆盖范围、心智模型和使用注意事项完全不同。两种方案总览转换发生在哪一层决定了它覆盖什么维度knexSnakeCaseMappersknex 层snakeCaseMappersobjection 层挂载位置knex 配置对象通过展开运算符传入模型类的columnNameMappers静态属性转换机制knex 的wrapIdentifier与postProcessResponse钩子objection 模型的列名映射器column name mappers表名 / 列名写法全部使用 camelCasepersonsTable、firstName仍使用 snake_casepersons_table、first_namerelationMappings写法camelCasesnake_case查询条件.where()等camelCasesnake_case模型实例属性camelCasecamelCaseinsert/patch/update入参camelCasecamelCase由$formatDatabaseJson自动转回 snake_caseobjection 对数据库的感知完全无感知只看到 camelCase 的世界知道底层是 snake_case仅在结果对象与写入对象两侧做转换关键结论knexSnakeCaseMappers在 knex 层就把一切标识符表名、列名、别名、关系连接列从 camelCase 翻译成 snake_case并同时把返回结果行中的列名翻译回 camelCase因此 objection 从头到尾只见得到 camelCase而snakeCaseMappers只负责结果行 → 模型实例属性与写入对象 → 数据库列这两条数据通路查询与关系映射仍需按数据库实际命名书写。方案一knexSnakeCaseMappers —— 在 knex 层完成全局转换原理两个 knex 钩子knexSnakeCaseMappers的底层实现见 lib/utils/identifierMapping.jsfunction knexSnakeCaseMappers(opt {}) { return knexIdentifierMappers({ parse: (str) camelCase(str, opt), format: (str) snakeCase(str, opt), }); }而knexIdentifierMappers同文件 L172-L196最终返回一个包含两个钩子的对象wrapIdentifier(identifier, origWrap)在 SQL 构建阶段把查询里出现的每个标识符表名、列名、别名用format即snakeCase转换后再交给 knex 原生的包裹逻辑。这保证了.where(firstName, ...)最终生成的 SQL 里是first_name。postProcessResponse(result)在查询结果返回时把结果行或行数组的每个键用parse即camelCase转换因此模型实例拿到的属性天然是firstName。由于这两个钩子由 knex 在 objection 接收数据之前执行所以 objection 完全不知道数据库里存的是 snake_case——它看到的表、列、关系连接全部是 camelCase。完整配置示例假设数据库表结构如下来自 配方文档exports.up knex { return knex.schema.createTable(persons_table, table { table.increments(id_column).primary(); table.string(first_name); table.string(last_name); table.integer(parent_id).references(persons_table.id_column); }); }; exports.down knex { return knex.schema.dropTableIfExists(persons_table); };在 knex 配置中启用转换const Knex require(knex); const { Model, knexSnakeCaseMappers } require(objection); const knex Knex({ client: postgres, connection: { host: 127.0.0.1, user: objection, database: objection_test } // 如果列是 UPPER_SNAKE_CASE可以使用 // knexSnakeCaseMappers({ upperCase: true }) ...knexSnakeCaseMappers() });此时模型定义必须全部使用 camelCaseclass Person extends Model { static get tableName() { return personsTable; } static get idColumn() { return idColumn; } static get relationMappings() { return { parent: { relation: Model.BelongsToOneRelation, modelClass: Person, join: { from: personsTable.parentId, to: personsTable.idColumn } } }; } }查询同样使用 camelCaseawait Person.query().where(firstName, Jennifer);personsTable、idColumn、personsTable.parentId会在 SQL 构建阶段分别被翻译为persons_table、id_column、persons_table.parent_id。注意这里的parentId引用的是列虽然它和模型属性的parentId拼写一致但语义上是数据库标识符由 knex 层负责转换。支持的选项knexSnakeCaseMappers接受一个选项对象完整选项表见 api/objection 文档选项类型默认值说明upperCasebooleanfalse设为true以适配UPPER_SNAKE_CASE命名的列underscoreBeforeDigitsbooleanfalse为true时在数字前加下划线foo1Bar2→foo_1_bar_2为false时foo1Bar2→foo1_bar2underscoreBetweenUppercaseLettersbooleanfalse为true时在连续大写字母间加下划线fooBAR→foo_b_a_r为false时fooBAR→foo_bar方案二snakeCaseMappers —— 在 objection 层转换原理columnNameMappers 与模型数据通路snakeCaseMappers返回的是一个{ parse, format }对象lib/utils/identifierMapping.js#L165-L170它通过模型的columnNameMappers静态属性接入 objection 的数据通路。在 lib/model/Model.js 中可以确认其调用位置$parseDatabaseJson(json)数据库行进入模型实例前先执行columnNameMappers.parse(json)把first_name转为firstName$formatDatabaseJson(json)模型实例写入数据库前先执行columnNameMappers.format(json)把firstName转回first_name。正是后者保证了文档中的关键结论insert、patch、update及其变体仍然接收 camelCase 对象——因为客户端传来的 camelCase 对象会在此处被自动格式化为 snake_case 列名后写入数据库。完整配置示例使用snakeCaseMappers时模型仍然按照数据库实际命名定义const { Model, snakeCaseMappers } require(objection); class Person extends Model { static get columnNameMappers() { // 如果列是 UPPER_SNAKE_CASE可以使用 // snakeCaseMappers({ upperCase: true }) return snakeCaseMappers(); } static get tableName() { return persons_table; } static get idColumn() { return id_column; } static get relationMappings() { return { parent: { relation: Model.BelongsToOneRelation, modelClass: Person, join: { from: persons_table.parent_id, to: persons_table.id_column } } }; } }查询需要按照数据库命名书写await Person.query().where(first_name, Jennifer);支持的选项snakeCaseMappers接受与knexSnakeCaseMappers完全相同的选项对象api/objection 文档upperCase、underscoreBeforeDigits、underscoreBetweenUppercaseLetters默认值均为false含义与上表一致。在源码中这两个函数都把选项原样透传给底层的snakeCase/camelCase实现lib/utils/identifierMapping.js#L24-L115因此二者的转换规则完全对齐。两种方式如何选择项目希望全链路 camelCase团队希望模型类、关系映射、所有查询条件乃至 knex 原生查询都统一写 camelCase并且不希望 objection 层再做一层翻译——选择knexSnakeCaseMappers。它的覆盖最彻底代价是你必须只使用 camelCase 书写所有标识符混用 snake_case 反而会出错。项目希望数据库命名透明化团队希望保留数据库的 snake_case 可见性关系映射和复杂查询按 SQL 习惯书写仅让模型实例属性与写入对象享受 camelCase 便利——选择snakeCaseMappers。它的侵入面小只挂在一个静态属性上且可以按模型粒度启用。需要逐模型开关snakeCaseMappers放在columnNameMappers里天然支持每个模型类独立启用/禁用knexSnakeCaseMappers是全局性的一旦启用会影响所有使用该 knex 实例的查询。已有大量 snake_case 查询与关系映射的存量代码迁移到snakeCaseMappers的改动更小只需为模型添加一个 getter而knexSnakeCaseMappers需要重写所有表名、列名与关系定义。源码深挖identifierMapping 的实现细节转换算法本身snakeCase与camelCase的手写实现位于 lib/utils/identifierMapping.js#L24-L115。值得注意的两个实现细节非 ASCII 字符安全源码注释明确指出该实现同时支持非 ASCII 字符这是因为 objection 内部会使用包含:字符的别名如table:relation形式转换器必须能正确处理这类输入而不破坏内部标识符。camelCase的upperCase兼容当upperCase: true且字符串为全大写 snake_case 时会先转小写再驼峰化同时允许已是 camelCase 的字符串原样通过lib/utils/identifierMapping.js#L92-L97。keyMapper 与 memoize两个映射器都通过keyMapperlib/utils/identifierMapping.js#L147-L163作用于对象键仅当输入是普通对象非数组时才逐键映射非对象输入原样返回。同时用memoize同文件 L5-L19缓存单参数函数结果避免对重复出现的列名反复执行字符串转换这对大批量结果行的性能是有利的。idSeparatorobjection 内部别名的处理knexIdentifierMappers支持idSeparator参数默认:通过mapLastPartlib/utils/identifierMapping.js#L136-L143只转换最后一个分隔符之后的部分。这是刻意设计objection 在 eager loading、关系查询等场景内部会构造personsTable:parent这类复合标识符冒号前的表名部分保持原样只有最后一段参与转换从而保证内部机制不被破坏。knexIdentifierMapping自定义任意映射如果命名规则不是标准的 snake_case/camelCase 关系仓库还提供了knexIdentifierMappinglib/utils/identifierMapping.js#L205-L215它接收一个colToProp映射对象在parse时把列名映射为属性名、在format时反向映射未命中的标识符原样通过。典型用法见 api/objection 文档例如把MyId、MyProp映射为id、prop甚至可以遍历所有模型的jsonSchema.properties自动生成映射表。它同样返回wrapIdentifierpostProcessResponse钩子机制与knexSnakeCaseMappers完全一致。测试与验证仓库的集成测试对两种方案均有覆盖可作为行为契约参考tests/integration/snakeCase.js验证snakeCaseMappers的查询、插入、关系加载以及upperCase: true分支如FIRST_NAME→firstNametests/integration/knexSnakeCase.js验证knexSnakeCaseMappers挂载到 knex 配置后的全链路行为同样包含大写变体测试其他场景测试如 tests/integration/misc/#1467.js、tests/integration/misc/concurrency.js也通过snakeCaseMappers验证了它在关系钩子、并发查询等复杂场景下的稳定性。常见坑与边界情况不要混用两种方案的书写习惯使用knexSnakeCaseMappers时模型与查询中出现任何 snake_case 标识符都不会被转换会直接落到 SQL 中导致列不存在使用snakeCaseMappers时关系映射和查询条件必须保持 snake_case写成 camelCase 同样报错。大写蛇形命名列名是UPPER_SNAKE_CASE如FIRST_NAME时必须显式传入{ upperCase: true }否则转换结果不符合预期。数字与连续大写字母列名含数字如floor1Name或连续大写如fooBAR时可通过underscoreBeforeDigits、underscoreBetweenUppercaseLetters精确控制转换结果建议在启用前用小型脚本验证目标列名全部能按预期往返转换。写入方向的对象snakeCaseMappers下insert/patch/update的入参对象仍是 camelCase由$formatDatabaseJson负责反向转换不要手动先转成 snake_case 再传入否则会得到双重转换的错误列名。JSON 列属性两种映射器均通过keyMapper只作用于对象顶层键lib/utils/identifierMapping.js#L147-L163JSON 列内部的嵌套字段名不会被转换而 JSON 列的序列化由jsonAttributes机制在模型层单独处理见 lib/model/modelJsonAttributes.js两者互不干扰。赞分享数据库后端【免费下载链接】objection.jsAn SQL-friendly ORM for Node.js项目地址https://gitcode.com/gh_mirrors/ob/objection.js点击查看免费下载相关推荐Absinthe适配器配置camelCase与snake_case转换的完整指南Absinthe适配器配置camelCase与snake_case转换的完整指南 想要在Elixir GraphQL项目中优雅地处理命名约定转换吗Absin后端深度解密Tampermonkey脚本依赖管理从require到resource的完整实践指南深度解密Tampermonkey脚本依赖管理从require到resource的完整实践指南 Tampermonkey作为拥有超过1000万用户的浏览器用前端插件系统go-strcase 字符串命名转换指南CamelCase、snake_case 与 kebab-case 的源码级解析与 KubeSphere 实战go strcase 字符串命名转换指南CamelCase、snake_case 与 kebab case 的源码级解析与 KubeSphere 实战 导读后端云原生容器编排微服务上一篇Laguna-XS-2.1-6bit核心技术解密混合注意力机制与MoE架构如何实现25GB显存高效运行下一篇PHP变量作用域终极指南clean-code-php项目中的最小权限原则实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 objection.js 中 snake_case 与 camelCase 的自动转换：knexSnakeCaseMappers 与 snakeCaseMappers 完整实战指南
数据库后端【免费下载链接】objection.jsAn SQL-friendly ORM for Node.js项目地址https://gitcode.com/gh_mirrors/ob/objection.js点击查看免费下载在数据库中使用snake_case命名first_name、parent_id而在 JavaScript 代码中使用camelCase命名firstName、parentId是 Node.js 后端项目最常见的命名习惯之一。objection.js 针对这一需求提供了两套官方解决方案knex 层的knexSnakeCaseMappers和 objection 层的snakeCaseMappers。本文将基于 snake-case-to-camel-case-conversion 配方文档结合仓库源码lib/utils/identifierMapping.js、lib/model/Model.js与集成测试深入讲解这两种方案的原理、配置、选项与选型建议帮助你根据自己的项目结构选择正确的转换方式。为什么需要 snake_case / camelCase 转换关系型数据库中的列名通常遵循snake_case约定如first_name而 JavaScript/TypeScript 社区则普遍采用camelCase风格如firstName。如果让代码与数据库直接使用同一套命名会产生两难要么代码中出现大量下划线命名的属性要么数据库中出现驼峰命名的列两者都破坏各自生态的惯例。objection.js 提供的核心价值在于转换是自动的、可配置的你不需要在每个模型里手写$parseDatabaseJson/$formatDatabaseJson来做字段映射。官方给出了两种截然不同的实现位置它们的覆盖范围、心智模型和使用注意事项完全不同。两种方案总览转换发生在哪一层决定了它覆盖什么维度knexSnakeCaseMappersknex 层snakeCaseMappersobjection 层挂载位置knex 配置对象通过展开运算符传入模型类的columnNameMappers静态属性转换机制knex 的wrapIdentifier与postProcessResponse钩子objection 模型的列名映射器column name mappers表名 / 列名写法全部使用 camelCasepersonsTable、firstName仍使用 snake_casepersons_table、first_namerelationMappings写法camelCasesnake_case查询条件.where()等camelCasesnake_case模型实例属性camelCasecamelCaseinsert/patch/update入参camelCasecamelCase由$formatDatabaseJson自动转回 snake_caseobjection 对数据库的感知完全无感知只看到 camelCase 的世界知道底层是 snake_case仅在结果对象与写入对象两侧做转换关键结论knexSnakeCaseMappers在 knex 层就把一切标识符表名、列名、别名、关系连接列从 camelCase 翻译成 snake_case并同时把返回结果行中的列名翻译回 camelCase因此 objection 从头到尾只见得到 camelCase而snakeCaseMappers只负责结果行 → 模型实例属性与写入对象 → 数据库列这两条数据通路查询与关系映射仍需按数据库实际命名书写。方案一knexSnakeCaseMappers —— 在 knex 层完成全局转换原理两个 knex 钩子knexSnakeCaseMappers的底层实现见 lib/utils/identifierMapping.jsfunction knexSnakeCaseMappers(opt {}) { return knexIdentifierMappers({ parse: (str) camelCase(str, opt), format: (str) snakeCase(str, opt), }); }而knexIdentifierMappers同文件 L172-L196最终返回一个包含两个钩子的对象wrapIdentifier(identifier, origWrap)在 SQL 构建阶段把查询里出现的每个标识符表名、列名、别名用format即snakeCase转换后再交给 knex 原生的包裹逻辑。这保证了.where(firstName, ...)最终生成的 SQL 里是first_name。postProcessResponse(result)在查询结果返回时把结果行或行数组的每个键用parse即camelCase转换因此模型实例拿到的属性天然是firstName。由于这两个钩子由 knex 在 objection 接收数据之前执行所以 objection 完全不知道数据库里存的是 snake_case——它看到的表、列、关系连接全部是 camelCase。完整配置示例假设数据库表结构如下来自 配方文档exports.up knex { return knex.schema.createTable(persons_table, table { table.increments(id_column).primary(); table.string(first_name); table.string(last_name); table.integer(parent_id).references(persons_table.id_column); }); }; exports.down knex { return knex.schema.dropTableIfExists(persons_table); };在 knex 配置中启用转换const Knex require(knex); const { Model, knexSnakeCaseMappers } require(objection); const knex Knex({ client: postgres, connection: { host: 127.0.0.1, user: objection, database: objection_test } // 如果列是 UPPER_SNAKE_CASE可以使用 // knexSnakeCaseMappers({ upperCase: true }) ...knexSnakeCaseMappers() });此时模型定义必须全部使用 camelCaseclass Person extends Model { static get tableName() { return personsTable; } static get idColumn() { return idColumn; } static get relationMappings() { return { parent: { relation: Model.BelongsToOneRelation, modelClass: Person, join: { from: personsTable.parentId, to: personsTable.idColumn } } }; } }查询同样使用 camelCaseawait Person.query().where(firstName, Jennifer);personsTable、idColumn、personsTable.parentId会在 SQL 构建阶段分别被翻译为persons_table、id_column、persons_table.parent_id。注意这里的parentId引用的是列虽然它和模型属性的parentId拼写一致但语义上是数据库标识符由 knex 层负责转换。支持的选项knexSnakeCaseMappers接受一个选项对象完整选项表见 api/objection 文档选项类型默认值说明upperCasebooleanfalse设为true以适配UPPER_SNAKE_CASE命名的列underscoreBeforeDigitsbooleanfalse为true时在数字前加下划线foo1Bar2→foo_1_bar_2为false时foo1Bar2→foo1_bar2underscoreBetweenUppercaseLettersbooleanfalse为true时在连续大写字母间加下划线fooBAR→foo_b_a_r为false时fooBAR→foo_bar方案二snakeCaseMappers —— 在 objection 层转换原理columnNameMappers 与模型数据通路snakeCaseMappers返回的是一个{ parse, format }对象lib/utils/identifierMapping.js#L165-L170它通过模型的columnNameMappers静态属性接入 objection 的数据通路。在 lib/model/Model.js 中可以确认其调用位置$parseDatabaseJson(json)数据库行进入模型实例前先执行columnNameMappers.parse(json)把first_name转为firstName$formatDatabaseJson(json)模型实例写入数据库前先执行columnNameMappers.format(json)把firstName转回first_name。正是后者保证了文档中的关键结论insert、patch、update及其变体仍然接收 camelCase 对象——因为客户端传来的 camelCase 对象会在此处被自动格式化为 snake_case 列名后写入数据库。完整配置示例使用snakeCaseMappers时模型仍然按照数据库实际命名定义const { Model, snakeCaseMappers } require(objection); class Person extends Model { static get columnNameMappers() { // 如果列是 UPPER_SNAKE_CASE可以使用 // snakeCaseMappers({ upperCase: true }) return snakeCaseMappers(); } static get tableName() { return persons_table; } static get idColumn() { return id_column; } static get relationMappings() { return { parent: { relation: Model.BelongsToOneRelation, modelClass: Person, join: { from: persons_table.parent_id, to: persons_table.id_column } } }; } }查询需要按照数据库命名书写await Person.query().where(first_name, Jennifer);支持的选项snakeCaseMappers接受与knexSnakeCaseMappers完全相同的选项对象api/objection 文档upperCase、underscoreBeforeDigits、underscoreBetweenUppercaseLetters默认值均为false含义与上表一致。在源码中这两个函数都把选项原样透传给底层的snakeCase/camelCase实现lib/utils/identifierMapping.js#L24-L115因此二者的转换规则完全对齐。两种方式如何选择项目希望全链路 camelCase团队希望模型类、关系映射、所有查询条件乃至 knex 原生查询都统一写 camelCase并且不希望 objection 层再做一层翻译——选择knexSnakeCaseMappers。它的覆盖最彻底代价是你必须只使用 camelCase 书写所有标识符混用 snake_case 反而会出错。项目希望数据库命名透明化团队希望保留数据库的 snake_case 可见性关系映射和复杂查询按 SQL 习惯书写仅让模型实例属性与写入对象享受 camelCase 便利——选择snakeCaseMappers。它的侵入面小只挂在一个静态属性上且可以按模型粒度启用。需要逐模型开关snakeCaseMappers放在columnNameMappers里天然支持每个模型类独立启用/禁用knexSnakeCaseMappers是全局性的一旦启用会影响所有使用该 knex 实例的查询。已有大量 snake_case 查询与关系映射的存量代码迁移到snakeCaseMappers的改动更小只需为模型添加一个 getter而knexSnakeCaseMappers需要重写所有表名、列名与关系定义。源码深挖identifierMapping 的实现细节转换算法本身snakeCase与camelCase的手写实现位于 lib/utils/identifierMapping.js#L24-L115。值得注意的两个实现细节非 ASCII 字符安全源码注释明确指出该实现同时支持非 ASCII 字符这是因为 objection 内部会使用包含:字符的别名如table:relation形式转换器必须能正确处理这类输入而不破坏内部标识符。camelCase的upperCase兼容当upperCase: true且字符串为全大写 snake_case 时会先转小写再驼峰化同时允许已是 camelCase 的字符串原样通过lib/utils/identifierMapping.js#L92-L97。keyMapper 与 memoize两个映射器都通过keyMapperlib/utils/identifierMapping.js#L147-L163作用于对象键仅当输入是普通对象非数组时才逐键映射非对象输入原样返回。同时用memoize同文件 L5-L19缓存单参数函数结果避免对重复出现的列名反复执行字符串转换这对大批量结果行的性能是有利的。idSeparatorobjection 内部别名的处理knexIdentifierMappers支持idSeparator参数默认:通过mapLastPartlib/utils/identifierMapping.js#L136-L143只转换最后一个分隔符之后的部分。这是刻意设计objection 在 eager loading、关系查询等场景内部会构造personsTable:parent这类复合标识符冒号前的表名部分保持原样只有最后一段参与转换从而保证内部机制不被破坏。knexIdentifierMapping自定义任意映射如果命名规则不是标准的 snake_case/camelCase 关系仓库还提供了knexIdentifierMappinglib/utils/identifierMapping.js#L205-L215它接收一个colToProp映射对象在parse时把列名映射为属性名、在format时反向映射未命中的标识符原样通过。典型用法见 api/objection 文档例如把MyId、MyProp映射为id、prop甚至可以遍历所有模型的jsonSchema.properties自动生成映射表。它同样返回wrapIdentifierpostProcessResponse钩子机制与knexSnakeCaseMappers完全一致。测试与验证仓库的集成测试对两种方案均有覆盖可作为行为契约参考tests/integration/snakeCase.js验证snakeCaseMappers的查询、插入、关系加载以及upperCase: true分支如FIRST_NAME→firstNametests/integration/knexSnakeCase.js验证knexSnakeCaseMappers挂载到 knex 配置后的全链路行为同样包含大写变体测试其他场景测试如 tests/integration/misc/#1467.js、tests/integration/misc/concurrency.js也通过snakeCaseMappers验证了它在关系钩子、并发查询等复杂场景下的稳定性。常见坑与边界情况不要混用两种方案的书写习惯使用knexSnakeCaseMappers时模型与查询中出现任何 snake_case 标识符都不会被转换会直接落到 SQL 中导致列不存在使用snakeCaseMappers时关系映射和查询条件必须保持 snake_case写成 camelCase 同样报错。大写蛇形命名列名是UPPER_SNAKE_CASE如FIRST_NAME时必须显式传入{ upperCase: true }否则转换结果不符合预期。数字与连续大写字母列名含数字如floor1Name或连续大写如fooBAR时可通过underscoreBeforeDigits、underscoreBetweenUppercaseLetters精确控制转换结果建议在启用前用小型脚本验证目标列名全部能按预期往返转换。写入方向的对象snakeCaseMappers下insert/patch/update的入参对象仍是 camelCase由$formatDatabaseJson负责反向转换不要手动先转成 snake_case 再传入否则会得到双重转换的错误列名。JSON 列属性两种映射器均通过keyMapper只作用于对象顶层键lib/utils/identifierMapping.js#L147-L163JSON 列内部的嵌套字段名不会被转换而 JSON 列的序列化由jsonAttributes机制在模型层单独处理见 lib/model/modelJsonAttributes.js两者互不干扰。赞分享数据库后端【免费下载链接】objection.jsAn SQL-friendly ORM for Node.js项目地址https://gitcode.com/gh_mirrors/ob/objection.js点击查看免费下载相关推荐Absinthe适配器配置camelCase与snake_case转换的完整指南Absinthe适配器配置camelCase与snake_case转换的完整指南 想要在Elixir GraphQL项目中优雅地处理命名约定转换吗Absin后端深度解密Tampermonkey脚本依赖管理从require到resource的完整实践指南深度解密Tampermonkey脚本依赖管理从require到resource的完整实践指南 Tampermonkey作为拥有超过1000万用户的浏览器用前端插件系统go-strcase 字符串命名转换指南CamelCase、snake_case 与 kebab-case 的源码级解析与 KubeSphere 实战go strcase 字符串命名转换指南CamelCase、snake_case 与 kebab case 的源码级解析与 KubeSphere 实战 导读后端云原生容器编排微服务上一篇Laguna-XS-2.1-6bit核心技术解密混合注意力机制与MoE架构如何实现25GB显存高效运行下一篇PHP变量作用域终极指南clean-code-php项目中的最小权限原则实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考