gRPC C 的 AI 协作开发指南类型选择、代码风格与 Bazel 构建规范详解【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc在 gRPC 这样体量的 C 代码库中如何让 AI Agent或人类新人快速写出符合仓库惯例的代码是决定协作效率的关键。gRPC 官方在仓库根目录提供了 AGENTS.mdgRPC C Agents Collaboration Guide系统性地定义了 AI 辅助开发时的类型选型、代码风格与 Bazel 构建约定。本文基于该文档展开逐条解析其约定背后的工程原因并对照仓库源码如 bazel/grpc_build_system.bzl、test/core/end2end/BUILD给出可验证的实现依据帮助你在为 gRPC 提交代码前建立正确的惯例直觉。一、类型与库的选型优先级AGENTS.md 的 Preferred Tools Libraries 一节给出了一个清晰的依赖优先级链条。它不是风格偏好而是直接约束了代码在 C、Python 等多语言绑定下能否正确编译与链接。1.1 类型选择的三级优先序原文约定如下按优先级从高到低优先使用 gRPC 自有类型其次才是 absl 类型可用std类型时优先std不可用时再用absl具体到选项类型优先std::optional而不是absl::optional语言标准锁定在 C17不能使用 C20 及以后的类型。第 4 条有明确的构建系统佐证。CMake 构建中Apple 平台未显式指定标准时会默认回落到 C17见 CMakeLists.txtif (APPLE AND NOT DEFINED CMAKE_CXX_STANDARD) message(CMAKE_CXX_STANDARD was undefined, defaulting to C17.) set(CMAKE_CXX_STANDARD 17) endif()而 BUILDING.md 的构建命令、官方 C 示例的 examples/cpp/cmake/common.cmakeset(CMAKE_CXX_STANDARD 17)并CMAKE_CXX_STANDARD_REQUIRED True也都统一按 C17 配置。因此std::span、std::format、concepts、std::expectedC23等新特性都不可用需要类似能力时应评估 absl 对应组件。1.2 Python 绑定不能依赖 protobuf C 库原文还有一条跨语言约束Python 实现不能依赖 protobuf 库因此所有与 Python 共享的库必须暴露不依赖 C protobuf 类型的 C 风格 API。这条约定的落点在 gRPC 的公开 C 头文件层例如 include/grpc/grpc.h 这类纯 C 接口头以及 include/grpc/slice.h 的grpc_slice抽象——Cython 层src/python/grpcio正是通过 C API 与 core 交互从而绕过 C protobuf 依赖。从源码结构看凡是打算被 Python 复用的能力都应下沉到这一层 C 接口而不是直接在 C 类上暴露google::protobuf::*类型。二、代码风格约定Code Style ConventionsAGENTS.md 的 Code Style Conventions 共列出 8 条硬性约定逐条拆解如下。2.1 头文件包含纪律#include grpc/support/port_platform.h不是必须包含除非编译确实需要其中的宏。这条约定避免了历史上每个文件都无脑包含 port_platform造成的噪音只包含实际用到的头文件Abseil 头文件排在 gRPC 头文件之前即 include 分组的固定顺序先 absl后 grpc公开 API 头文件位于include/grpc必须用尖括号全路径形式包含例如#include grpc/grpc.h对应仓库中真实存在的公开头 include/grpc/grpc.h。这一点在 C17 模块化过渡期参见 doc/core/moving-to-c.md 的讨论背景尤其重要相对路径 include 会破坏公开 API 只经由 include 根解析的封装边界。2.2 返回值类型拒绝std::pair/std::tuple原文要求优先显式类型而不是std::pair或std::tuple作为返回类型。工程含义是当函数需要返回两个语义不同的值时应定义一个具名结构体或std::variant让调用点出现result.status、result.count这类自文档化字段而不是result.first、std::get1(result)。这在 review 中是可机器检查的惯例。2.3 日志只用LOG(ERROR)错误日志必须使用 absl/log/log.h 的LOG(ERROR)禁止使用std::cerr或gpr_log。gpr_log是 gRPC 早期自有日志设施仓库正处于向 absl 日志迁移的过程中gRPC core 的 C 风格日志与 C absl 日志并存因此新代码一律走 absl 通道保证日志级别、格式与采样策略统一。2.4 其他细节约定fuzz 测试头文件位置fuzztest.h位于fuzztest/fuzztest.h。在 test/core/end2end/BUILD 的注释中可以看到fuzztest 与 CMake 基础设施尚未完全打通fuzztest isnt yet integrated with our cmake infrastructure所以 fuzztest 相关目标主要出现在 Bazel 构建中未使用的具名参数unused named parameters直接视为编译失败这是 gRPC 严格的编译警告策略的一部分写函数签名时必须确保每个形参都被消费或按仓库惯例显式消解否则 CI 编译即失败。三、Bazel 构建体系gRPC 自有规则速查AGENTS.md 的 About gRPC 一节信息密度最高共 12 条约定。核心思想是gRPC 不用裸 Bazel 规则而是用bazel/grpc_build_system.bzl中封装的一层自有宏直接写cc_library/cc_test会绕过平台选择、默认 copts、可见性修正等逻辑。3.1 每个目录必须有grpc_package每个 Bazel 包目录都应声明一个grpc_package目标。其实现位于 bazel/grpc_build_system.bzldef grpc_package(name, visibility private, features []):库目标用grpc_cc_librarybazel/grpc_build_system.bzl测试目标用grpc_cc_testbazel/grpc_build_system.bzl。从grpc_cc_library的实现可以看到它做了大量隐式工作统一注入GRPC_DEFAULT_COPTS编译选项含严格的警告开关按平台追加 linkopts非 Windows 加-pthreadWindows 加-defaultlib:ws2_32.lib通过select注入GRPC_ARES0、GRPC_ALLOW_EXCEPTIONS0/1等构建开关对应的宏定义修正可见性自动补//:__subpackages__与//bazel:friends。grpc_cc_test则在cc_test之外额外生成name_TEST_LIBRARY形式的cc_library并适配 iOS 测试目标这些细节正是不要用裸cc_test的原因。3.2external_deps外部依赖的统一命名空间依赖 gtest、absl 等非 gRPC 库时不写com_google_absl//...全路径而是写进external_deps属性。名字到实际目标的映射由_get_external_deps完成规则表如下直接从源码提取external_deps写法实际解析目标xxx开头原样保留xxhash//third_party/xxhashcares//third_party:caresgrpc_no_ares配置下为空protobufcom_google_protobuf//:protobufprotobuf_clibprotobuf 的code_generatorimporterprotobuf_headersprotobuf_headers io 相关子包absl/xxxcom_google_absl//xxxgoogle/xxxcom_google_googleapis//xxxotel/xxxio_opentelemetry_cpp//xxxgoogle_cloud_cpp/xxxgoogle_cloud_cpp//xxx其他//third_party:xxx两个高频细节gtest这个 external_dep 同时包含gmock声明external_deps [gtest]即可同时使用两者的头文件从源码结构看fuzztest 有特殊处理external_deps中出现fuzztest时会自动给目标打上grpc-fuzztest标签bazel/grpc_build_system.bzl因为 fuzztest 库本身暂用了一些 C20 扩展需要与 C17 的主代码隔离编译。3.3 铁律:grpc目标不得依赖 C protobuf原文规定:grpc这个 BUILD target 不允许直接或间接依赖 C protobuf 库。这是 gRPC 依赖架构的边界约束core 数据面slice、byte_buffer、C API 层必须保持 protobuf-free序列化相关的耦合被隔离在单独的绑定层。这与 2.1 节Python 不能依赖 protobuf是同一条边界线的两个侧面——任何在//:grpc的deps里引入com_google_protobuf的改动都会破坏 C 语言用户与 Python 绑定的假设。3.4 BUILD 文件的分布规则实现代码的 BUILD 文件集中在 src/core/BUILD 与根目录 BUILD除非有明确指示不要在src/树下新增 BUILD 文件。这意味着新增 core 源码时通常是在已有的大型 BUILD 文件里追加 target而不是拆包测试位于 test/core 与 test/cpp分别对应src/core、src/cpp等源码目录这些测试目录各自维护 BUILD 文件所有upb相关构建规则grpc_upb_proto_library、grpc_upb_proto_reflection_library必须定义在根目录 BUILD 中即使 proto 定义在其他子目录里。根 BUILD 中已有大量此类规则例如从 BUILD 起连续定义的多个grpc_upb_proto_library目标把 upb 生成物集中在一个文件里便于 upb 工具链版本与生成参数统一管理。3.5 一个高价值的避坑提示grpc_proto_library的 target 命名原文特别警告依赖grpc_proto_library时对应cc_library的名字就是grpc_proto_library规则自己的name而不是按标准 Bazelcc_proto_library惯例会预期的[name]_cc_proto且构建系统的报错信息在此场景下会误导人。实际含义如果你在 BUILD 里写deps [:hello_cc_proto]然后得到一个看似不相关的错误先怀疑是这里——正确写法是直接引用 proto 规则同名 target。这是新人以及 Agent在 gRPC 仓库里最容易踩的构建坑之一建议修改 proto 依赖时优先对照根 BUILD 里现有写法的命名。四、核心端到端测试套件grpc_core_end2end_test_suite机制AGENTS.md 用一整段描述了 end2end 测试的生成机制值得单独展开因为它解释了 test/core/end2end/BUILD 里为什么一份配置能跑出一堆测试。4.1 宏的行为宏定义在 test/core/end2end/grpc_core_end2end_test.bzl关键参数为name套件名且必须对应一个test/name.cc风格的测试集合config_src实现End2endTestConfigs()函数的 C 配置文件描述 transport 特性如是否支持代理、重试、资源配额等deps配置所需额外依赖enable_fuzzing、with_no_logging_test等开关。宏内部test/core/end2end/grpc_core_end2end_test.bzl生成规则为grpc_cc_test( name name _test, srcs [config_src] [ //test/core/end2end:tests/%s.cc % t for t in _TESTS ], external_deps _EXTERNAL_DEPS [gtest_main], ... )即把config_src与 test/core/end2end/tests/ 下的每个测试实现文件_TESTS列表中的simple_request、retry、ping_pong_streaming、write_buffering等拼成一个测试二进制最终 target 名 name_test。4.2 一个真实示例根文档举的例子在仓库中可以逐字对照见 test/core/end2end/BUILDgrpc_core_end2end_test_suite( name end2end_http2, config_src end2end_http2_config.cc, flaky True, tags [ grpc:no-internal-poller, ], deps [ //:iomgr, //src/core:arena, //src/core:chaotic_good_connector, //src/core:chaotic_good_server, //src/core:context, //src/core:env, //src/core:metrics, //src/core:slice_buffer, //src/core:sync, ], )它最终生成测试 target//test/core/end2end:end2end_http2_test。同文件中还有end2end_vrpc等多个套件各自指向不同config_src同一套tests/用例在不同 transport 配置下重复验证——这就是配置 × 测试矩阵式的端到端覆盖思路。4.3 Fuzz 测试入口差异与 end2end 套件使用gtest_main不同fuzz 测试使用fuzztest_main。从 test/core/end2end/BUILD 的注释可以看到同一批 end2end 测试会按是否启用 fuzztest 生成后缀不同的库_fuzztest/_no_fuzztestfuzztest 版本走 fuzz 引擎而非 gtest 主入口。五、约定速查清单把 AGENTS.md 的全部约定浓缩为提交前检查表类别约定类型gRPC 类型 stdabsl用std::optional只用 C17 特性跨语言与 Python 共享的代码必须走不依赖 C protobuf 类型的 C 风格 APIInclude按需包含port_platform.h只用到的头才包含absl 头先于 gRPC 头公开 API 用#include grpc/...API 设计返回多值用具名显式类型不用std::pair/std::tuple日志只用absl/log/log.h的LOG(ERROR)禁用std::cerr与gpr_logBazel每目录grpc_package库用grpc_cc_library测试用grpc_cc_test外部依赖走external_deps依赖边界:grpc禁止依赖 C protobuf含传递依赖BUILD 布局core 构建集中在 src/core/BUILD 与根 BUILD不在src/下随意新增 BUILDprotoupb 规则一律放根 BUILDgrpc_proto_library的 cc 目标名等于规则name本身测试测试位于 test/core、test/cppfuzz 用fuzztest_mainend2end 用grpc_core_end2end_test_suite目标名为name_test工具链gtest隐式包含gmock未使用的具名参数会导致编译失败六、小结AGENTS.md 的三条主线——类型选型的依赖层级、严格的 C/C 边界protobuf 隔离、以及自有 Bazel 规则体系——共同勾勒出 gRPC C 代码库的协作契约。对 AI Agent 而言这份文档的价值在于把仓库里散落各处的隐性惯例external_deps 映射、end2end 宏的生成规则、proto 目标命名陷阱显式化为可执行的检查项对人工开发者而言它同样是一份高效的 onboarding 清单。配合 bazel/grpc_build_system.bzl 中各宏的参数文档与 test/core/end2end/BUILD 中的真实用例可以按需深入任何一条约定的实现细节。【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 gRPC C++ 的 AI 协作开发指南：类型选择、代码风格与 Bazel 构建规范详解
gRPC C 的 AI 协作开发指南类型选择、代码风格与 Bazel 构建规范详解【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc在 gRPC 这样体量的 C 代码库中如何让 AI Agent或人类新人快速写出符合仓库惯例的代码是决定协作效率的关键。gRPC 官方在仓库根目录提供了 AGENTS.mdgRPC C Agents Collaboration Guide系统性地定义了 AI 辅助开发时的类型选型、代码风格与 Bazel 构建约定。本文基于该文档展开逐条解析其约定背后的工程原因并对照仓库源码如 bazel/grpc_build_system.bzl、test/core/end2end/BUILD给出可验证的实现依据帮助你在为 gRPC 提交代码前建立正确的惯例直觉。一、类型与库的选型优先级AGENTS.md 的 Preferred Tools Libraries 一节给出了一个清晰的依赖优先级链条。它不是风格偏好而是直接约束了代码在 C、Python 等多语言绑定下能否正确编译与链接。1.1 类型选择的三级优先序原文约定如下按优先级从高到低优先使用 gRPC 自有类型其次才是 absl 类型可用std类型时优先std不可用时再用absl具体到选项类型优先std::optional而不是absl::optional语言标准锁定在 C17不能使用 C20 及以后的类型。第 4 条有明确的构建系统佐证。CMake 构建中Apple 平台未显式指定标准时会默认回落到 C17见 CMakeLists.txtif (APPLE AND NOT DEFINED CMAKE_CXX_STANDARD) message(CMAKE_CXX_STANDARD was undefined, defaulting to C17.) set(CMAKE_CXX_STANDARD 17) endif()而 BUILDING.md 的构建命令、官方 C 示例的 examples/cpp/cmake/common.cmakeset(CMAKE_CXX_STANDARD 17)并CMAKE_CXX_STANDARD_REQUIRED True也都统一按 C17 配置。因此std::span、std::format、concepts、std::expectedC23等新特性都不可用需要类似能力时应评估 absl 对应组件。1.2 Python 绑定不能依赖 protobuf C 库原文还有一条跨语言约束Python 实现不能依赖 protobuf 库因此所有与 Python 共享的库必须暴露不依赖 C protobuf 类型的 C 风格 API。这条约定的落点在 gRPC 的公开 C 头文件层例如 include/grpc/grpc.h 这类纯 C 接口头以及 include/grpc/slice.h 的grpc_slice抽象——Cython 层src/python/grpcio正是通过 C API 与 core 交互从而绕过 C protobuf 依赖。从源码结构看凡是打算被 Python 复用的能力都应下沉到这一层 C 接口而不是直接在 C 类上暴露google::protobuf::*类型。二、代码风格约定Code Style ConventionsAGENTS.md 的 Code Style Conventions 共列出 8 条硬性约定逐条拆解如下。2.1 头文件包含纪律#include grpc/support/port_platform.h不是必须包含除非编译确实需要其中的宏。这条约定避免了历史上每个文件都无脑包含 port_platform造成的噪音只包含实际用到的头文件Abseil 头文件排在 gRPC 头文件之前即 include 分组的固定顺序先 absl后 grpc公开 API 头文件位于include/grpc必须用尖括号全路径形式包含例如#include grpc/grpc.h对应仓库中真实存在的公开头 include/grpc/grpc.h。这一点在 C17 模块化过渡期参见 doc/core/moving-to-c.md 的讨论背景尤其重要相对路径 include 会破坏公开 API 只经由 include 根解析的封装边界。2.2 返回值类型拒绝std::pair/std::tuple原文要求优先显式类型而不是std::pair或std::tuple作为返回类型。工程含义是当函数需要返回两个语义不同的值时应定义一个具名结构体或std::variant让调用点出现result.status、result.count这类自文档化字段而不是result.first、std::get1(result)。这在 review 中是可机器检查的惯例。2.3 日志只用LOG(ERROR)错误日志必须使用 absl/log/log.h 的LOG(ERROR)禁止使用std::cerr或gpr_log。gpr_log是 gRPC 早期自有日志设施仓库正处于向 absl 日志迁移的过程中gRPC core 的 C 风格日志与 C absl 日志并存因此新代码一律走 absl 通道保证日志级别、格式与采样策略统一。2.4 其他细节约定fuzz 测试头文件位置fuzztest.h位于fuzztest/fuzztest.h。在 test/core/end2end/BUILD 的注释中可以看到fuzztest 与 CMake 基础设施尚未完全打通fuzztest isnt yet integrated with our cmake infrastructure所以 fuzztest 相关目标主要出现在 Bazel 构建中未使用的具名参数unused named parameters直接视为编译失败这是 gRPC 严格的编译警告策略的一部分写函数签名时必须确保每个形参都被消费或按仓库惯例显式消解否则 CI 编译即失败。三、Bazel 构建体系gRPC 自有规则速查AGENTS.md 的 About gRPC 一节信息密度最高共 12 条约定。核心思想是gRPC 不用裸 Bazel 规则而是用bazel/grpc_build_system.bzl中封装的一层自有宏直接写cc_library/cc_test会绕过平台选择、默认 copts、可见性修正等逻辑。3.1 每个目录必须有grpc_package每个 Bazel 包目录都应声明一个grpc_package目标。其实现位于 bazel/grpc_build_system.bzldef grpc_package(name, visibility private, features []):库目标用grpc_cc_librarybazel/grpc_build_system.bzl测试目标用grpc_cc_testbazel/grpc_build_system.bzl。从grpc_cc_library的实现可以看到它做了大量隐式工作统一注入GRPC_DEFAULT_COPTS编译选项含严格的警告开关按平台追加 linkopts非 Windows 加-pthreadWindows 加-defaultlib:ws2_32.lib通过select注入GRPC_ARES0、GRPC_ALLOW_EXCEPTIONS0/1等构建开关对应的宏定义修正可见性自动补//:__subpackages__与//bazel:friends。grpc_cc_test则在cc_test之外额外生成name_TEST_LIBRARY形式的cc_library并适配 iOS 测试目标这些细节正是不要用裸cc_test的原因。3.2external_deps外部依赖的统一命名空间依赖 gtest、absl 等非 gRPC 库时不写com_google_absl//...全路径而是写进external_deps属性。名字到实际目标的映射由_get_external_deps完成规则表如下直接从源码提取external_deps写法实际解析目标xxx开头原样保留xxhash//third_party/xxhashcares//third_party:caresgrpc_no_ares配置下为空protobufcom_google_protobuf//:protobufprotobuf_clibprotobuf 的code_generatorimporterprotobuf_headersprotobuf_headers io 相关子包absl/xxxcom_google_absl//xxxgoogle/xxxcom_google_googleapis//xxxotel/xxxio_opentelemetry_cpp//xxxgoogle_cloud_cpp/xxxgoogle_cloud_cpp//xxx其他//third_party:xxx两个高频细节gtest这个 external_dep 同时包含gmock声明external_deps [gtest]即可同时使用两者的头文件从源码结构看fuzztest 有特殊处理external_deps中出现fuzztest时会自动给目标打上grpc-fuzztest标签bazel/grpc_build_system.bzl因为 fuzztest 库本身暂用了一些 C20 扩展需要与 C17 的主代码隔离编译。3.3 铁律:grpc目标不得依赖 C protobuf原文规定:grpc这个 BUILD target 不允许直接或间接依赖 C protobuf 库。这是 gRPC 依赖架构的边界约束core 数据面slice、byte_buffer、C API 层必须保持 protobuf-free序列化相关的耦合被隔离在单独的绑定层。这与 2.1 节Python 不能依赖 protobuf是同一条边界线的两个侧面——任何在//:grpc的deps里引入com_google_protobuf的改动都会破坏 C 语言用户与 Python 绑定的假设。3.4 BUILD 文件的分布规则实现代码的 BUILD 文件集中在 src/core/BUILD 与根目录 BUILD除非有明确指示不要在src/树下新增 BUILD 文件。这意味着新增 core 源码时通常是在已有的大型 BUILD 文件里追加 target而不是拆包测试位于 test/core 与 test/cpp分别对应src/core、src/cpp等源码目录这些测试目录各自维护 BUILD 文件所有upb相关构建规则grpc_upb_proto_library、grpc_upb_proto_reflection_library必须定义在根目录 BUILD 中即使 proto 定义在其他子目录里。根 BUILD 中已有大量此类规则例如从 BUILD 起连续定义的多个grpc_upb_proto_library目标把 upb 生成物集中在一个文件里便于 upb 工具链版本与生成参数统一管理。3.5 一个高价值的避坑提示grpc_proto_library的 target 命名原文特别警告依赖grpc_proto_library时对应cc_library的名字就是grpc_proto_library规则自己的name而不是按标准 Bazelcc_proto_library惯例会预期的[name]_cc_proto且构建系统的报错信息在此场景下会误导人。实际含义如果你在 BUILD 里写deps [:hello_cc_proto]然后得到一个看似不相关的错误先怀疑是这里——正确写法是直接引用 proto 规则同名 target。这是新人以及 Agent在 gRPC 仓库里最容易踩的构建坑之一建议修改 proto 依赖时优先对照根 BUILD 里现有写法的命名。四、核心端到端测试套件grpc_core_end2end_test_suite机制AGENTS.md 用一整段描述了 end2end 测试的生成机制值得单独展开因为它解释了 test/core/end2end/BUILD 里为什么一份配置能跑出一堆测试。4.1 宏的行为宏定义在 test/core/end2end/grpc_core_end2end_test.bzl关键参数为name套件名且必须对应一个test/name.cc风格的测试集合config_src实现End2endTestConfigs()函数的 C 配置文件描述 transport 特性如是否支持代理、重试、资源配额等deps配置所需额外依赖enable_fuzzing、with_no_logging_test等开关。宏内部test/core/end2end/grpc_core_end2end_test.bzl生成规则为grpc_cc_test( name name _test, srcs [config_src] [ //test/core/end2end:tests/%s.cc % t for t in _TESTS ], external_deps _EXTERNAL_DEPS [gtest_main], ... )即把config_src与 test/core/end2end/tests/ 下的每个测试实现文件_TESTS列表中的simple_request、retry、ping_pong_streaming、write_buffering等拼成一个测试二进制最终 target 名 name_test。4.2 一个真实示例根文档举的例子在仓库中可以逐字对照见 test/core/end2end/BUILDgrpc_core_end2end_test_suite( name end2end_http2, config_src end2end_http2_config.cc, flaky True, tags [ grpc:no-internal-poller, ], deps [ //:iomgr, //src/core:arena, //src/core:chaotic_good_connector, //src/core:chaotic_good_server, //src/core:context, //src/core:env, //src/core:metrics, //src/core:slice_buffer, //src/core:sync, ], )它最终生成测试 target//test/core/end2end:end2end_http2_test。同文件中还有end2end_vrpc等多个套件各自指向不同config_src同一套tests/用例在不同 transport 配置下重复验证——这就是配置 × 测试矩阵式的端到端覆盖思路。4.3 Fuzz 测试入口差异与 end2end 套件使用gtest_main不同fuzz 测试使用fuzztest_main。从 test/core/end2end/BUILD 的注释可以看到同一批 end2end 测试会按是否启用 fuzztest 生成后缀不同的库_fuzztest/_no_fuzztestfuzztest 版本走 fuzz 引擎而非 gtest 主入口。五、约定速查清单把 AGENTS.md 的全部约定浓缩为提交前检查表类别约定类型gRPC 类型 stdabsl用std::optional只用 C17 特性跨语言与 Python 共享的代码必须走不依赖 C protobuf 类型的 C 风格 APIInclude按需包含port_platform.h只用到的头才包含absl 头先于 gRPC 头公开 API 用#include grpc/...API 设计返回多值用具名显式类型不用std::pair/std::tuple日志只用absl/log/log.h的LOG(ERROR)禁用std::cerr与gpr_logBazel每目录grpc_package库用grpc_cc_library测试用grpc_cc_test外部依赖走external_deps依赖边界:grpc禁止依赖 C protobuf含传递依赖BUILD 布局core 构建集中在 src/core/BUILD 与根 BUILD不在src/下随意新增 BUILDprotoupb 规则一律放根 BUILDgrpc_proto_library的 cc 目标名等于规则name本身测试测试位于 test/core、test/cppfuzz 用fuzztest_mainend2end 用grpc_core_end2end_test_suite目标名为name_test工具链gtest隐式包含gmock未使用的具名参数会导致编译失败六、小结AGENTS.md 的三条主线——类型选型的依赖层级、严格的 C/C 边界protobuf 隔离、以及自有 Bazel 规则体系——共同勾勒出 gRPC C 代码库的协作契约。对 AI Agent 而言这份文档的价值在于把仓库里散落各处的隐性惯例external_deps 映射、end2end 宏的生成规则、proto 目标命名陷阱显式化为可执行的检查项对人工开发者而言它同样是一份高效的 onboarding 清单。配合 bazel/grpc_build_system.bzl 中各宏的参数文档与 test/core/end2end/BUILD 中的真实用例可以按需深入任何一条约定的实现细节。【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考