Bazel构建大型C++项目的核心是模块化声明、显式依赖与可复现构建。通过BUILD文件明确定义目标源码、头文件、依赖及编译选项，划分职责清晰的包边界，用cc_library封装可复用组件，严格管控visibility与第三方依赖，并利用缓存、查询与调试工具提升效率。
用 Bazel 构建大型 C++ 项目，核心是“模块化声明 + 显式依赖 + 可复现构建”。它不靠目录结构自动推断，而是靠 BUILD 文件明确定义每个目标的源码、头文件路径、依赖项和编译选项。对大型项目来说，这不是额外负担，而是控制复杂性的必要手段。
定义清晰的包（package）边界
Bazel 中的“包”由目录下存在 BUILD 或 BUILD.bazel 文件标识。每个包应有明确职责，比如 //src/network 封装网络模块，//src/storage 封装存储模块。避免跨包循环依赖，这是大型项目可维护的关键。
- 每个包只暴露必要的头文件，用
hdrs属性控制头文件可见性 - 内部实现头（如
impl/detail.h）不应出现在hdrs中，而放在srcs或私有子目录 - 包名尽量与命名空间一致（如包
//src/utils对应 C++ 命名空间myproject::utils），降低理解成本
用 cc_library 组织可复用组件
大型项目中，90% 的逻辑应封装为 cc_library，而非直接写在 cc_binary 里。每个库专注单一能力，通过依赖链组装功能。
- 基础库（如日志、字符串工具）放最底层，不依赖其他业务模块
- 业务模块库只依赖其直接需要的接口，避免“全量引入”——例如
auth_service库只需依赖//proto:auth_proto，而非整个//proto包 - 使用
visibility严格限制访问范围：visibility = ["//src/server:__pkg__"]表示仅允许同包内目标引用
管理第三方依赖：用 http_archive + bind 或 rules_cc
不要把第三方代码复制进仓库。Bazel 推荐通过 WORKSPACE 声明远程依赖，确保所有开发者使用完全相同的版本。
Google Search Grounding 3
下载
通过 Gemini 搜索落地（主）和 Custom Search JSON API（备）进行 Google 网页搜索。用途：(1) 附引用的综合回答（落地搜索），(2) 含摘要的原始链接结果，(3) 图片搜索。希伯来语支持极佳。优于内置 web_search (Perplexity)。
立即学习“C++免费学习笔记（深入）”；
- 用
http_archive下载预编译或源码（如 gRPC、abseil），配合patch_args修复构建兼容性问题 - 对未提供原生 Bazel 支持的库（如 OpenSSL），可用
new_local_repository指向本地已编译产物，或用cc_import导入 .so/.a - 避免在
cc_library中硬编码系统路径（如/usr/include/xxx），这会破坏沙箱隔离和跨平台能力
加速构建与调试：利用 Bazel 的缓存与分析能力
大型项目编译慢？问题往往不在 Bazel，而在构建逻辑本身。Bazel 提供精准的增量构建和远程缓存支持。
- 启用远程缓存（如 BuildBuddy 或自建 Redis 缓存），CI 和开发者共享构建结果，首次拉取后几乎秒级响应
- 用
bazel query 'deps(//src:main)'查看依赖图，发现意外的深层依赖；用bazel aquery分析实际执行的编译动作 - 调试时优先用
bazel run //src:main -- --flag=value，它自动重建并运行，比手动gdb启动更可靠
不复杂但容易忽略：从第一天起就让每个新模块都带 BUILD 文件，拒绝“先写完代码再补构建脚本”的思路。Bazel 的工程价值，恰恰藏在持续一致的构建契约里。
