后端【免费下载链接】google-api-nodejs-clientGoogles officially supported Node.js client library for accessing Google APIs. Support for authorization and authentication with OAuth 2.0, API Keys and JWT (Service Tokens) is included.项目地址https://gitcode.com/gh_mirrors/go/google-api-nodejs-client点击查看免费下载本篇指南以 google-api-nodejs-client 仓库中 firebaseappcheck 的 CHANGELOG 为核心脉络系统梳理googleapis/firebaseappcheck这个官方 Node.js 客户端库从 1.0.0 到 15.0.2 的版本演进、破坏性变更来源与工程化策略并结合仓库内自动生成的 v1 客户端源码 与 v1beta 客户端源码 给出可运行的使用示例。读完本文你将掌握该库的版本选择依据、Node 运行环境要求、资源与方法结构以及如何在你的后端服务中调用 Firebase App Check 的各类认证配置接口。一、这份 CHANGELOG 记录了什么src/apis/firebaseappcheck/CHANGELOG.md 是googleapis/firebaseappcheck独立 npm 子包package name 为googleapis/firebaseappcheck见 package.json的完整发布历史覆盖从1.0.02022-12-22到15.0.22026-10-03共数十个版本。它采用 standard-version/release-please 风格的条目格式每条记录包含三类信息Features新增能力绝大多数条目是firebaseappcheck: update the API即 Firebase App Check 服务端 OpenAPI 描述文件更新后重新生成客户端代码Bug Fixes缺陷修复同样多以firebaseappcheck: update the API形式出现偶见依赖升级如upgrade googleapis-common⚠ BREAKING CHANGES破坏性变更本库历史中主要来自生成器重构、Node 最低版本提升与依赖大版本升级。从源码结构看每个子包的 CHANGELOG 由仓库的自动化发布流水线generator release-please 配置参考仓库根目录的 release-please-config.json 与 synth.metadata按版本切分自动生成因此它既是包用户的升级手册也是观察 Google API 客户端库工程化节奏的一手资料。二、客户端库是什么Firebase App Check 与 googleapis/firebaseappcheck在深入版本历史之前先明确这份 CHANGELOG 所属的主体。根据 子包 README 的定位说明Firebase App Check works alongside other Firebase services to help protect your backend resources from abuse, such as billing fraud or phishing.Firebase App Check 与 Firebase 的其他服务协同工作用于保护你的后端资源免受滥用如计费欺诈或钓鱼攻击。客户端通过 Apple App Attest、Apple DeviceCheck、Google Play Integrity、reCAPTCHA Enterprise / reCAPTCHA v3 等平台证明能力换取签名 JWTApp Check Token后端服务校验该 Token 即可确认请求来自可信设备。googleapis/firebaseappcheck是访问Firebase App Check API服务基地址为https://firebaseappcheck.googleapis.com/见 v1.ts 中 rootUrl 常量的官方客户端。安装方式$ npm install googleapis/firebaseappcheck在 npm 包内部入口文件 index.ts 通过VERSIONS映射同时暴露两个 API 版本export const VERSIONS { v1: firebaseappcheck_v1.Firebaseappcheck, v1beta: firebaseappcheck_v1beta.Firebaseappcheck, };也可以不安装独立包而是使用聚合包googleapisconst {google} require(googleapis); const firebaseappcheck google.firebaseappcheck(v1);三、从 CHANGELOG 看版本演进主线把 CHANGELOG 中所有条目按时间轴排布可以清晰看到这条客户端的演进主线。1.0.02022-12-22生成器重构的起点首个版本即标记⚠ BREAKING CHANGES其 Feature 为run the generator (submodules now require Node 12)。这透露出两个信息一是子包从此要求Node 12 及以上二是该库的代码完全由生成器产出上游 API 一变客户端版本随之迭代。2023 年高频 API 同步5.x 时代2023 年 1 月至 10 月版本从 5.4.0 一路走到 5.3.1→5.5.0→5.6.x→5.7.0→5.8.0→5.9.0→5.10.0→5.11.0→5.12.0→5.13.0→5.14.02023-10-11几乎每次都以update the API同步上游描述文件。途中还发生一次update dependency googleapis-common to v7的依赖大版本升级并伴随多个run the generator批次。2024 年5.14 平台期与 6.x/7.x 的 Node 18 迁移2024 年 2 月至 10 月集中在 5.6.05.14.22025 年 5 月起进入 6.0.0、7.0.0两个大版本均以upgrade to node 18为 BREAKING CHANGES即最低 Node 版本从 12 提升到 18。同时googleapis-common被升级到 8.0.0#3731与 8.0.2-rc。2025 年8.0.010.x 的连续重构2025 年 710 月7.0.1、8.0.0releasing for our librariesupgrade googleapis-common to 8.0.0、9.0.0、10.0.0 密集发布多次run the generator其中 8.0.0 把googleapis-common正式升到 8.0.0 大版本。2026 年Node 22 门槛与 11.x15.x2026 年 810 月版本从 11.0.0 快速推进到 15.0.2。关键的破坏性变更来自两处#4011Update apiary to minimum Node version of 22——生成器apiary 流水线要求最低 Node 229.0.014.0.0 均以此为主标记并伴随upgrade dependencies in generated packages to Node 22#4020Update apiary to minimum Node version of 22 again——15.0.0 再次确认该要求。期间还出现一次add back support for node 18为 Node 18 恢复支持的 Bug Fix说明团队在迁移 Node 22 过程中短暂回退又最终收敛。演进里程碑一览版本区间时间关键变更Node 最低要求1.0.02022-12-22子模块化生成器重构Node 125.x2023-01 2024-10高频update the APIgoogleapis-common v7Node 126.0.0 / 7.0.02025-05 2025-06upgrade to node 18Node 188.0.02025-09googleapis-common 8.0.0 大版本Node 1811.0.0 14.0.02026-08 2026-09#4011 最低 Node 22短暂恢复 Node 18Node 18 / 2215.0.0 15.0.22026-09 2026-10#4020 再次确认最低 Node 22API 同步Node 22这一演进与 package.json 当前声明的engines: {node: 22.0.0}、googleapis-common: ^9.0.0完全吻合——当前仓库版本的运行前提是 Node.js ≥ 22。四、BREAKING CHANGES 从何而来通读 CHANGELOG 可以发现标有⚠ BREAKING CHANGES的版本很少是因为 Firebase App Check API 本身的重构条目多为笼统的 This release has breaking changes而是集中在三类工程事件上生成器整体重跑run the generator生成器升级会批量改动所有子包的脚手架、类型定义与依赖声明如 1.0.0Node 12、8.0.0/9.0.0/10.0.0/11.0.0Node 最低版本策略调整6.0.0/7.0.0Node 18、13.0.0/14.0.0/15.0.0Node 22底层公共库googleapis-common大版本升级v6→v7→8.0.0→8.0.2-rc→9.0.0属于传递性依赖的破坏性变更。对使用方而言判断是否需要关注某个大版本优先看这三类条目即可API 字段增删往往只影响你调用的具体方法而 Node 版本与依赖升级会影响整个项目的运行环境。五、v1 客户端的资源与代码结构结合源码可以看到自动生成客户端的完整资源树v1.ts顶层Firebaseappcheck类L113-L128挂载三个资源jwks、oauthClients、projectsprojects.appsL1637-L1662之下按证明方式划分配置子资源appAttestConfig、debugTokens、deviceCheckConfig、playIntegrityConfig、recaptchaEnterpriseConfig、recaptchaV3Configprojects.services之下还有resourcePoliciesL7632 起用于批量更新 ResourcePolicy 配置jwks.getL767 起返回 RFC 7517 定义的公共 JWK 集合供后端校验 App Check Token 签名——返回集合中恰好有一把公钥能验证当前任意有效 Token。与证明能力对应的核心 Schema见 v1.ts 的 Schema 定义区包括AppCheckToken封装 Token签名 JWT含标识被证明 app 与 GCP project 的 claims及ttl有效期ExchangeAppAttestAssertionRequest/ExchangeAppAttestAttestationRequestApp Attest 两步交换协议先 attestation 换 artifact再 assertion 换 token所需字段artifact、assertion、challenge、keyId、limitedUseExchangeDebugTokenRequest、ExchangeDeviceCheckTokenRequest、ExchangePlayIntegrityTokenRequest、ExchangeRecaptchaEnterpriseTokenRequest、ExchangeCustomTokenRequest等DeviceCheckConfigL274-L295包含keyId、privateKeyInput only永不回显、privateKeySet唯一判断私钥是否已设置的途径、tokenTtl30 分钟7 天默认 1 小时DebugTokenL249-L270token必须为 UUID4、创建后不可读不可改只能通过DeleteDebugToken吊销每个 app 最多 20 个。六、实战从源码示例到可运行代码自动生成源码的每个方法都附带完整 JSDoc 示例含启用 API、gcloud auth application-default login、安装依赖三步准备下面选取三条最具代表性的链路整理成可直接复制的代码。1. 创建 Debug Token调试用创建 Debug Token 后token字段立即不可回显因此必须在响应中及时保存const {google} require(googleapis); const firebaseappcheck google.firebaseappcheck(v1); async function main() { const auth new google.auth.GoogleAuth({ scopes: [ https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/firebase, ], }); const authClient await auth.getClient(); google.options({auth: authClient}); const res await firebaseappcheck.projects.apps.debugTokens.create({ // Required. 父资源名格式: projects/{project_number}/apps/{app_id} parent: projects/my-project/apps/my-app, requestBody: { displayName: CI debug token, token: 00000000-0000-0000-0000-000000000000, // 必须是 UUID4 }, }); console.log(res.data); // 注意: 后续任何响应都不会再包含 token 字段 } main().catch(e { console.error(e); throw e; });方法定义与参数校验见 v1.ts 中 Debugtokens.create实现层要求requiredParams: [parent]。2. 交换 App Attest assertion 换取 App Check TokeniOS 端 App Attest 流程分两步先调用generateAppAttestChallenge拿一次性 challenge再exchangeAppAttestAttestation换 artifact最后用 artifactassertion 换 tokenconst res await firebaseappcheck.projects.apps.exchangeAppAttestAssertion({ app: projects/my-project/apps/my-app, requestBody: { artifact: my_artifact, // 上一次 Attestation 交换的产物 assertion: my_assertion, // 客户端 App Attest API 返回的 CBOR 断言 challenge: my_challenge, // 紧邻先前 GenerateAppAttestChallenge 的一次性挑战 limitedUse: false, // true 表示用于 replay protection 的 limited-use 场景 }, }); console.log(res.data); // {token, ttl}对应 Schema 与完整示例见 v1.ts L1664-L1756 与 ExchangeAppAttestAssertionRequest 定义。3. 批量获取 DeviceCheck 配置配置类子资源普遍提供batchGet一次最多取 100 个对象const res await firebaseappcheck.projects.apps.deviceCheckConfig.batchGet({ parent: projects/my-project, names: [ projects/my-project/apps/app-1/deviceCheckConfig, projects/my-project/apps/app-2/deviceCheckConfig, ], }); console.log(res.data); // {configs: [...]}注意出于安全考虑响应中的private_key字段永远不会被填充见 batchGet 文档注释只能通过privateKeySet判断是否已配置。七、v1 与 v1beta两代客户端的差异VERSIONS 映射 同时提供v1与v1beta。从 v1beta.ts 的搜索结果表明v1beta 同样以https://firebaseappcheck.googleapis.com/为 rootUrl但部分交换类端点挂在oauthClients资源下如oauthClients.exchangeAppAttestAssertion、oauthClients.exchangeDebugToken、oauthClients.generateAppAttestChallenge对应 URL 形如/v1beta/{app}:exchangeAppAttestAssertion而 v1 将同类方法置于projects.apps下。这是典型的前后端 API 命名演进——beta 版本承担新特性验证v1 则提供稳定契约。接入时建议以当前公开文档声明支持的版本身份为准通过google.firebaseappcheck(v1)或google.firebaseappcheck(v1beta)显式选择。八、工程化细节构建、浏览器打包与类型输出版本演进之外子包的工程化配置也值得了解TypeScript 构建tsconfig.json 继承gts/tsconfig-google.json输出到build/目录main与types分别指向build/index.js与build/index.d.ts浏览器/打包场景webpack.config.js 以index.ts为入口、输出Firebaseappcheck全局库名dist/firebaseappcheck.min.js并通过null-loader屏蔽google-auth-library的 Node 加密实现及https-proxy-agent、gcp-metadata、gtoken等 Node 专属依赖用stream-browserify等补齐浏览器 shim——这解释了为什么 CHANGELOG 中依赖与生成器升级会被视为破坏性变更依赖约束当前 package.json 依赖googleapis-common ^9.0.0与 CHANGELOG 中 v7→8.0.0→8.0.2-rc→9.0.0 的升级轨迹一一对应。九、升级与选型建议基于 CHANGELOG 的事实结合以上分析为你的项目选择版本时可遵循以下判断链先看 Node 版本当前仓库要求 Node ≥ 22engines字段若你的 CI/运行时仍停留 Node 18需锁定 11.0.012.0.0 之间短暂支持 Node 18 的版本或自行验证兼容性再看 breaking 来源update the API类条目通常只影响你用到的方法run the generator、googleapis-common大版本升级则需要回归测试整个调用链路关注安全相关字段语义privateKey、token均为 Input only 且永不回显参考 DebugToken Schema升级后应依赖privateKeySet等输出字段做状态判断v1 与 v1beta 分开跟踪beta 端点的 URL 与方法挂载位置与 v1 不同v1beta.ts 交换端点升级时应一并核对。十、总结与深入阅读googleapis/firebaseappcheck的 CHANGELOG 忠实记录了 Firebase App Check 客户端在三年内的演化从 Node 12 到 Node 22 的环境门槛提升、googleapis-common 底层依赖的四次大版本跃迁、以及随 API 描述文件高频同步的 5.x/15.x 迭代。对使用者而言这份文档既是升级清单也是理解自动生成型 API 客户端工程节奏的最佳窗口。若需进一步深入阅读完整版本记录CHANGELOG.md查看包入口与版本导出index.ts查看 v1 全部资源与 Schema 定义v1.ts查看 v1beta 交换类端点v1beta.ts查看子包说明与安装方式README.md查看依赖与 Node 版本约束package.json。赞分享后端【免费下载链接】google-api-nodejs-clientGoogles officially supported Node.js client library for accessing Google APIs. Support for authorization and authentication with OAuth 2.0, API Keys and JWT (Service Tokens) is included.项目地址https://gitcode.com/gh_mirrors/go/google-api-nodejs-client点击查看免费下载相关推荐google-api-nodejs-client 中 Indexing API 客户端库googleapis/indexing的版本演进与技术解读google api nodejs client 中 Indexing API 客户端库googleapis/indexing的版本演进与技术解读 本篇技后端google-api-nodejs-client 的 Poly API 客户端从 CHANGELOG 透视 googleapis/poly 版本演进与 v1 实现google api nodejs client 的 Poly API 客户端从 CHANGELOG 透视 googleapis/poly 版本演进与 v1后端卷积神经网络CNN从入门到实战基于 AI-For-Beginners 的卷积、池化与经典架构深度解析卷积神经网络CNN从入门到实战基于 AI For Beginners 的卷积、池化与经典架构深度解析 本篇文章围绕 AI For Beginners ht后端上一篇PRML马尔可夫链HMM在序列预测中的终极应用指南下一篇react-native-animatable源码中的性能指标代码覆盖率与性能基准创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考