LLVM项目深度拆解：从monorepo源码到自定义Pass实战-北京尧图网络

llvm-project这个名字在编译器圈子里几乎是无人不知的很多没接触过底层技术的同学最容易把它等同于一个编译器实际上它已经膨胀成了一个庞大的编译器基础设施宇宙。可能是Clang的报错信息太过经典也可能是Xcode的底层依赖太过深入人心导致大多数人对这个仓库的认知停留在给Apple做编译器的这一层。今天不聊新闻不列Vaporware特性清单直接从源码结构、构建流程、核心抽象到开发工作流把这个仓库彻底拆开看一眼顺便把我在实际使用中踩过的坑和总结出来的经验一并倒出来。1. 从GitHub拉下llvm-project后先搞清楚仓库里到底装了些什么很多人第一次clone这个仓库的时候看到目录列表会有点懵因为在顶层目录里既看不到传统意义上的源码主目录也看不到清晰的交叉编译链布局。它既有clang又有flang既有lld又有mlir看起来到处都是编译器相关的东西但彼此之间的依赖关系又不像普通项目那样一眼能看明白。这个仓库其实采用的是monorepo策略LLVM自身只是其中一个子目录Clang、LLD这些也各自持有自己的独立目录但它们共享同一个版本控制历史和通用基础设施。1.1 最重要的布局认知六个核心子项目的定位与作用llvm/真正的核心基础设施包含了IR中间表示的定义、优化Pass框架、目标描述文件、代码生成器、MC层和各类后端支持。这是整个宇宙的中心。clang/C/C/Objective-C前端将源码解析为AST并且生成LLVM IR。多数人使用LLVM的第一步就是从这里开始的它也是目前完全成熟、生产可用的前端。lld/链接器不是普通意义上的链接器而是利用LLVM库重新实现的、支持多架构的闪电链接器速度比GNU ld快不是一点半点尤其对C项目来说。mlir/Multi-Level Intermediate Representation这是编译器中非常值得关注的一部分主要面向异构计算、机器学习框架、高性能计算领域可以在不同抽象层级做变换和优化。polly/多面体优化框架主要针对循环嵌套做自动并行化和数据局部性优化的。compiler-rt/提供与目标平台相关的运行时库比如SanitizerASan、UBSan支撑、内置整数运算、profile工具等底层支持。如果说llvm/是地基clang/是门面lld/是出入口那mlir/就是目前最有想象力的一个扩展层而flang/在仓库里其实是Fortran前端。libc和libcabi则是C标准库的实现和compiler-rt一样都属于“以llvm-project为宿主面向生产生态”的支撑型组件。1.2 为什么要把这么多项目塞进一个仓库monorepo的好处与分析传统开源项目的做法是每个子项目独立建仓形成tensorflow、pytorch这种多仓库并行的格局。但LLVM选择了monorepo在主仓库中同步所有代码提交。这么做的好处非常直接当天提交到clang/的改动如果会导致llvm/中的某个Pass出现问题同一个commit里面就会暴露出来而不是等到依赖的独立仓库各自发布版本后再做集成测试。所有子项目共用同一份构建配置和工具链例如llvm-lit测试框架、FileCheck匹配工具、LLVMConfig.cmake配置模块等改一个公共头文件不需要跨仓库发PR等待然后自行修兼容。缺点也显而易见如果有人不小心动了llvm/下的公共API可能会导致clang/、mlir/等依赖它的项目全部编译失败这也是为什么LLVM社区的代码审查极其严格尤其是对头文件修改的审查几乎苛刻。2. 从源码构建LLVM构建系统的选择与参数调优心得既然搞清楚了仓库布局就会自然而然地想把它跑起来。这个名字看起来像一个正常的开源项目但它实际编译消耗的时间、磁盘空间和内存数绝对能让第一次接触的人吃点苦头。如果配置不当等一两个小时项目还在编译的状况非常常见。2.1 前置准备磁盘空间、内存要求、依赖项在没有官方预编译包的前提下源码构建LLVM需要较为明确的空间安排。一个包含Clang和LLD的DebugAssert构建占用的磁盘空间随随便便可以超过30GBRelease构建会稍微好一些但需要的编译时间也更长。建议预留至少60GB的磁盘空间来避免中途遇到磁盘满导致构建失败。依赖项方面Linux环境需要cmake、ninja、gcc或clang、python、zlib、libxml2等。macOS环境需要Xcode Command Line Tools同时建议使用Homebrew安装ninja和cmake。还需要一个较新版本的C编译器因为LLVM本身大量使用C17特性老旧的编译环境通常会遇到各种各样无法处理的模板错误。官方目前也逐步在往C20迁移所以编译器版本尽可能新一点会少踩很多坑。提示如果只是日常写代码或使用Clang功能建议直接安装发行版提供的预编译包不要做源码构建。但如果想改Clang、写Pass、跑MLIR实验源码构建的高成本就是必经之路。2.2 最省心的CMake配置组合是什么在我自己的实践中以下这组配置是兼顾构建速度和后续开发便利性的一个较好组合cmake -G Ninja \ -DCMAKE_BUILD_TYPERelease \ -DLLVM_ENABLE_PROJECTSclang;lld \ -DLLVM_ENABLE_ASSERTIONSON \ -DLLVM_OPTIMIZED_TABLEGENON \ -DCMAKE_C_COMPILERclang \ -DCMAKE_CXX_COMPILERclang \ ../llvm-project/llvm解释几个容易忽略的细节LLVM_ENABLE_ASSERTIONSON意为在构建的二进制中保留断言检查这对开发调试非常有用因为很多LLVM内部机制都依赖断言来验证IR合法性如果关闭就不好定位问题。LLVM_OPTIMIZED_TABLEGENON的意思是用于生成代码的TableGen工具本身使用Release模式编译。TableGen是LLVM的一种代码生成机制以较快的速度生成各种目标描述和Pass注册代码。默认情况下它随主项目一起Debug构建如果开启这个选项TableGen运行速度会有巨大提升尤其是在修改了Target目录下的.td文件需要重新生成时体验差别非常明显。CMAKE_C_COMPILER和CMAKE_CXX_COMPILER指定为Clang虽然GCC也能编译LLVM但Clang编译LLVM的速度和产出二进制性能普遍更好且能避免一些GCC特有的模板问题。每次修改CMake缓存时不再需要重新从头构建Ninja会尽可能增量更新。这是最核心的优势。2.3 增量构建的瓶颈TableGen重跑与模板实例化的取舍我在增量为LLVM加了一个新Pass后重新构建大概要等五分钟如果布局合理这已经不算慢了。但有几次只是在X86.td里加了一条指令定义就触发了巨量依赖重建整个Target目录几乎都重编了一遍。这里有个瓶颈是未正确分隔两个部分TableGen的.td文件改动会重新生成TableGen的输出文件进而影响几乎所有后端文件。模板实例化的大量开销是编译器自身的代价高频修改模板代码会比修改普通C函数慢得多。应对方法是在开发Pass时尽量不要动Target目录下的文件在改动llvm/include/llvm/IR下的核心头文件前先审视是否真的需要因为这些头文件几乎被所有Pass依赖随便改个声明就相当于全仓库重新编译。2.4 构建过程中常见的编译错误与抖动处理内存不足导致编译进程被Kill可以使用-DLLVM_PARALLEL_LINK_JOBS2限制并行的链接任务数。链接阶段的内存消耗比编译阶段高得多如果机器内存不到32GB建议将并行链接限制在2或者更低。缺少libffi-dev或libedit-dev导致cmake配置失败这是Linux上遇到比较多的状况根据发行版安装对应的-dev包即可而python3版本过低也会导致LLVM构建脚本找不到合适的解释器。CMake提示找不到ninja确认已经安装ninja且cmake -G Ninja能正常识别。可以用cmake --version检查同时注意Python包ninja二进制和系统级ninja命令是两回事。这些都是我在平时接触得比较多的问题。解决时不要一股脑全改配置重来先确认错误是来自编译阶段还是链接阶段再针对性处理会高效很多。3. 吃透LLVM的核心抽象从IR到SelectionDAG再到后端指令选择LLVM之所以在编译器领域占据一个重要位置不是因为它的前端语法解析有多强而是它定义了一套优秀的中间表示——LLVM IR。Clang生成的IR是llvm-project的上层语言而后续优化、目标代码生成、指令选择这些全链路能力全都围绕IR展开。理解IR是真正推开llvm-project那扇门的第一步。3.1 LLVM IR的三种形态文本、内存态与bitcodeLLVM IR有三种等价表示方式文本格式.ll人类可读适合调试和阅读使用llvm-dis可以从bitcode还原。内存格式编译器内部容器的数据结构例如Module、Function、BasicBlock、Instruction这些C类就存在于llvm/IR/目录下。bitcode格式.bc二进制编码可以在磁盘上表示IR常用于LTO等场景。主流开发流程中代码先经过Clang生成bitcode或文本IR再进入opt工具。比如clang -S -emit-llvm foo.c -o foo.ll opt -passesmem2reg foo.ll -S -o foo.opt.ll llc foo.opt.ll -o foo.s这三条命令基本串起了从源码到汇编的核心路径Clang负责前端opt执行中间层优化llc负责代码生成。理解每条命令的作用后再去看任何和LLVM相关的优化流程都会感觉顺眼不少。3.2 Pass基础设施New PM与Legacy PM的演化逻辑优化Pass是LLVM中最核心的扩展机制。早期版本中Pass以Legacy PM旧版PassManager方式注册和运行接口是继承FunctionPass等基类。这种设计简单易懂但存在多个问题无法对Pass依赖进行精确管理无法天然支持并发分析。不利于按Pass管线为单位做缓存和查询。从LLVM 14开始New Pass Manager新Pass管理器成为默认最重要变化是引入AnalysisManager机制把分析和变换分开。变换Pass使用PreservedAnalyses告诉框架它修改了什么哪些分析结果需要失效或保留。这个机制进一步让Pass管线变得可组合也更方便在多线程环境下运行。我自己写优化Pass的经验是在新PM模型下尽量不继承某个具体类而是直接实现PassInfoMixinMyPass重写run方法并返回PreservedAnalyses::all()或相应集合。例如#include llvm/IR/PassManager.h #include llvm/IR/Function.h using namespace llvm; class MyPass : public PassInfoMixinMyPass { public: PreservedAnalyses run(Function F, FunctionAnalysisManager AM) { // 在这里对函数做数据流分析或变换 return PreservedAnalyses::all(); } };这样的设计让Pass不依赖全局状态更加符合现代C风格也更加可测。3.3 代码生成后端SelectionDAG、FastISel与GlobalISel的关系虽然IR层占据了优化的核心但真正把IR变成具体机器指令的是代码生成后端。llvm-project对不同的架构提供灵活的后端选择但无论什么目标平台大体绕不开这三套机制SelectionDAG最稳定、最成熟的指令选择框架。它把IR转换为一个DAG有向无环图然后基于模式匹配把DAG节点映射为具体指令。性能很好但编译开销偏高。FastISel面向调试场景的快速指令选择不以生成最优代码为目标而是追求极快的编译速度但生成的代码质量一般较差。GlobalISel新一代框架把指令选择抽象成更模块化、可扩展的阶段目标是兼顾快速编译与高质量代码生成。目前AArch64已经是默认使用GlobalISel的X86和RISC-V上也逐渐成熟。这里的核心认知是现代编译器不再是源码到汇编码的简单翻译器而是一个经过多层抽象、多级通用化表达的复杂流水线。IR是中间方舟DAG是后端内部的另一层中间表示真正支撑起多架构支持的是TableGen描述的指令模式。3.4 TableGen还远没到淘汰的时候尤其是后端开发很多人问我TableGen到底是不是一门编程语言从定义语法层面上看它不是图灵完备的编程语言并不能直接支持循环、递归等手段但它有非常强大的声明式描述能力和代码展开能力通过class、multiclass、foreach、let在编译期生成大量重复代码。比如X86架构的指令集描述文件X86.td就非常庞大包含了上千条指令定义如果没有TableGen手写这些指令匹配代码几乎是不可能的。在我添加自定义指令或修改指令寻址方式的时候一般使用以下流程在X86InstrInfo.td或对应的目标架构*InstrInfo.td中添加指令定义。在X86ISelLowering.cpp中对接Lowering逻辑。在X86AsmParser.cpp中增加汇编解析支持。重新构建并运行llvm-mc验证反汇编结果。TableGen生成的代码会被打包到build/lib/Target/X86/下如果构建产物没有同步更新在检查代码时会看到明显不一致的情况这时一定要先确认构建确实重新运行了TableGen。4. 写一个自定义优化Pass并跑起来从注册机制到测试验证进入LLVM开发最快的路径就是写一个属于自己的优化Pass让它在opt工具中能被加载执行。这看起来难其实有既定套路可以借鉴。下面以新Pass Manager为例演示从零开始写一个简单的常量传播加强版示例顺便把注册、编译、测试整条链路串起来。4.1 源码文件布局和CMake集成在llvm/lib/Transforms/下新建一个目录比如MyTransforms里面创建MyTransforms.cpp存放Pass实现CMakeLists.txt描述模块构建add_llvm_component_library(LLVMMyTransforms MyTransforms.cpp DEPENDS intrinsics_gen LINK_COMPONENTS Core Support )这段CMake声明以组件形式生成一个名为LLVMMyTransforms的库并显式依赖Core和Support。如果Pass要引用其他分析需要在LINK_COMPONENTS中补对应组件名称。4.2 Pass实现要点run方法、PreservedAnalyses与调试输出以一个简单的把add立即数指令替换为or为例示意性质并不建议这样做#include llvm/IR/Function.h #include llvm/IR/InstrTypes.h #include llvm/IR/Instructions.h #include llvm/Passes/PassBuilder.h #include llvm/Passes/PassPlugin.h #include llvm/Passes/PassManager.h using namespace llvm; namespace { class MyPass : public PassInfoMixinMyPass { public: PreservedAnalyses run(Function F, FunctionAnalysisManager AM) { bool Changed false; for (BasicBlock BB : F) { for (Instruction I : BB) { if (auto *BO dyn_castBinaryOperator(I)) { if (BO-getOpcode() Instruction::Add) { BO-setHasNoUnsignedWrap(true); BO-setHasNoSignedWrap(true); Changed true; } } } } return Changed ? PreservedAnalyses::none() : PreservedAnalyses::all(); } }; } // namespace llvm::PassPluginLibraryInfo getMyPassPluginInfo() { return { LLVM_PLUGIN_API_VERSION, MyPass, LLVM_VERSION_STRING, [](PassBuilder PB) { PB.registerPipelineParsingCallback( [](StringRef Name, FunctionPassManager FPM, ArrayRefPassBuilder::PipelineElement) { if (Name my-pass) { FPM.addPass(MyPass()); return true; } return false; }); }}; } extern C LLVM_ATTRIBUTE_WEAK ::llvm::PassPluginLibraryInfo llvmGetPassPluginInfo() { return getMyPassPluginInfo(); }这个实现里值得注意的有几点dyn_castBinaryOperator是一种RTTI风格的运行期类型转换LLVM中大量使用这种模式来保留类型安全。PreservedAnalyses::none()表示这次变换破坏了大部分分析结果需要重新计算如果什么都没改则all()让分析结果保留节省后续Pass重复计算时间。在注册PassPlugin时回调里通过Name my-pass才能让opt -passesmy-pass正确识别并执行。4.3 构建、加载和验证使用这个Pass的完整流程是cd build ninja LLVMMyTransforms opt -load-pass-plugin./lib/LLVMMyTransforms.so -passesmy-pass -S input.ll -o output.ll如果加载失败多数原因是插件编译时的LLVM版本和运行时opt版本不一致。LLVM生态非常关注编译版本和接口的稳定性插件一旦跨版本构建连接符号通常不匹配报错信息能直接看到版本号差异按照报错信息重新用当前build目录下的opt测试即可。测试上最好使用llvm-lit来做正则断言匹配。例如在测试目录下创建一个.ll测试文件; RUN: opt -load-pass-plugin%libdir/LLVMMyTransforms.so -passesmy-pass -S %s | FileCheck %s define i32 add_nuw_nsw(i32 %a, i32 %b) { %r add i32 %a, %b ret i32 %r } ; CHECK: add i32 %a, %b ; CHECK-SAME: nuw nswFileCheck是LLVM测试基础设施中最核心的验证工具CHECK这一行用来逐字匹配输出结果%s表示当前测试文件路径。这样写测试的目的在于把Pass行为固化下来避免后续修改时出现行为回归。5. 给llvm-project提交补丁的完整工作流与个人经验当你开始习惯在本地编译和调试并且产生了值得分享的修复或功能时自然会考虑向llvm-project提交PR。llvm-project不采用普通的developer直接往master推代码这种模式代码审查、CI强度、签名要求都比较高。5.1 Fork仓库、创建Branch、保持与上游同步基础流程git clone https://github.com/llvm/llvm-project.git cd llvm-project git remote add upstream https://github.com/llvm/llvm-project.git git fetch upstream git checkout -b my-fix与一般开源项目不同llvm-project的主干通常保持非常激进的变化频率每天可能有几十到上百个commit。因此分支越短越好尽量分而治之一次PR解决一个问题。在提交前运行git fetch upstream git rebase upstream/main来把改动基于最新主干之上交互式rebase把commit压成一个可以让reviewer的审查过程更轻松。5.2 phabricator时代结束后的GitHub PR流程llvm-project曾长期使用Phabricator进行代码审查但从2023年开始全面转向GitHub PR流程。现在只需要正常fork、push分支然后提交PR在PR描述中详细说明变更动机、编译和测试方法即可。有一个细节是提交信息前应当包含对应的子系统名例如[clang][CodeGen]、[LLD][ELF]、[MLIR][Transforms]这有助于CI流水线自动匹配对应的测试集和负责人。5.3 代码风格红线clang-format、命名规范、注释质量LLVM有着严格的代码风格强制要求这是很多初次提交补丁的人容易忽略的部分。检查方式通常是clang-format --styleLLVM file.cpp formatted.cpp git diff --check命名上类使用PascalCase函数和变量使用camelCase成员变量使用首字母小写等。注释方面强调“解释为什么而不解释是什么”避免写一句// Loop这种毫无提示的信号。我在提交补丁时遇到的比较常见的问题是忘记在头文件中也包括完整的文档注释LLVM要求公共头文件中的类、函数都写///注释或者在某些情况下把using namespace llvm;放进头文件这些都会在review阶段被直接要求改掉。想提交补丁前最好先跑一遍ninja check-llvm check-clang确认没有引入回归。5.4 本地测试的正确姿势check-llvm、check-clang和单项测试之间如何选择完整跑一遍check-llvm和check-clang可能需要一两个小时。如果只是想验证某个特定的Pass可以使用llvm-lit指定测试文件或目录llvm-lit -sv test/Transforms/MyTransforms/-sv可以输出详细信息方便看到FileCheck验证失败时的具体差异。每次提交前至少要确保自己改动的模块相关测试通过。如果CI已经在GitHub上跑通本地只需要跑与该更改相关的子集就可以了。6. 基于实战视角的常见误区与效率建议其实编译和维护llvm-project并不需要天才般的智商更多靠的是对基础设施的熟悉和踩坑经验。很多初学者把大量时间浪费在反复全量编译上而不是优化开发循环的局部更新过程。6.1 误区一开发必需DebugAssertions配置确实默认的Release配置会隐藏大量IR和Pass中的断言信息遇到错误时很难定位。但这不等于每次都必须用Debug模式跑全部模块。我的经验是用Release构建加Assertions启用也就是前面提到的-DLLVM_ENABLE_ASSERTIONSON加-DCMAKE_BUILD_TYPERelease这是性能和调试能力之间的一个较好平衡点。Debug模式下编译时间明显增加执行速度却慢很多跑测试用例的效率并不可观。当涉及复杂的数据流分析或指令选择问题时再切换Debug更容易拿到完整调用栈。6.2 误区二用GCC作为唯一编译器快速构建LLVMGCC编译LLVM很少出现不可逾越的障碍但Clang编译Clang带来的体验提升是实际可感的尤其是模板错误信息的准确度和编译速度表现。另一点是如果你本意就是调试Clang前端行为那么一直用GCC来构建也不利于复现用户环境中的问题。6.3 误区三修改头文件后只构建自己所在子目录LLVM的头文件相互依赖层级很深修改一个头文件后只有完整构建一遍所有依赖该头文件的组件才能保证没有被破坏掉。增量构建不会自动识别所有间接依赖。可以用ninja check-llvm来验证整体正确性但这不代表不需要重新编译其他组件。至少我自己修改llvm/include/llvm/IR/Instructions.h后一定会在本地跑一次完整ninja否则提交到CI后大概率会在别的模块里失败毕竟头文件和被依赖位置的距离可能比想象中远得多。6.4 效率建议ccache能在多大程度上帮到你LLVM的编译过程主要耗时在C的模板实例化和大量优化代码上使用ccache可以大幅减少重复修改同一文件后的重建时间。配置如下ccache --max-size50G cmake -DCMAKE_C_COMPILER_LAUNCHERccache \ -DCMAKE_CXX_COMPILER_LAUNCHERccache \ ../llvm-project/llvm但注意当改动非常底层例如修改了PassManager的公共接口时即便有ccache依赖传递范围内的文件依然需要重新执行预处理和编译只是少了一部分重复的编译工作这种情况下加速效果有限。对于频繁改动单个Pass文件、希望在迭代中省下大量时间的开发场景ccache还是比较值得启用的。6.5 独立工具链思维从llvm-project的一个组件出发而不是“整体设计”很多人以为llvm-project只能作为一个整体被编译这是一个常见误解。C生态里常见的做法是使用Spack、vcpkg或conda安装预编译的LLVM然后独立编写Pass插件插件通过-load-pass-plugin在opt中加载并不需要从头编译整个llvm-project。只有在需要修改Clang本体或者LLVM核心Pass时才值得投入全量构建的成本。如果只是学习IR、Pass机制或者想给特定目标写指令选择实验最好的路径是安装发行版自带的llvm-dev包按照头文件接口写一个独立插件项目大幅降低试错成本。这对上手理解llvm-project的核心机制非常有帮助而且能更快积累有效经验后再切入全量开发。7. 从仓库消费者到核心开发者的跨越一些长期主义建议llvm-project的代码量远超常人对编译器三个字的预期即使只读核心IR和Pass部分也需要大量时间沉淀。对于真正想走编译器开发方向的人我的建议是带着一个具体目标去读代码而不是盲目遍历目录。比如你想理解模式匹配在Instruction Selection中的作用就直接给llvm/test/CodeGen/X86/下某个指令选择相关的测试文件加日志看它在SelectionDAG的哪个阶段被选中追踪到X86ISelDAGToDAG.cpp的匹配逻辑。你会发现某个指令的pattern其实不过是TableGen生成的一张静态查表而真正复杂的语义分析已经被前端和IR层消化掉了。在追踪过程中使用llvm-mca可以查看指令的微架构调度情况llvm-objdump可以查看反汇编输出llvm-readobj能解析目标文件的结构信息。这些工具全部由同一个基础设施提供不用跨仓库找功能这种完整获得感是其他编译器项目难以替代的。另外想提醒的是不要忽视文档的力量。官方文档中Writing an LLVM Pass、LLVM Language Reference Manual和The LLVM Target-Independent Code Generator这三份文档语言虽然不够通俗却是最权威、最不会过时的核心读物。第一次读不懂也非常正常拿起文档对照源码再用少量测试用例去验证来两三轮之后基本就能形成自己的编译流水线认知体系。回到开头那个问题llvm-project到底是个什么东西它是一套经过十几年进化的编译器工具箱孕育出Clang、LLD、MLIR这些跨越多领域的系统。它不像大多数开源项目那样按说明书操作就能跑起来而是需要你先理解设计理念再动手调整。一旦翻过编译和修改的坎整个现代编译基础设施的地图就会在眼前慢慢展开这种掌控感能给你的技术判断力带来非常深远的支撑。

LLVM项目深度拆解：从monorepo源码到自定义Pass实战

相关推荐

PostHog Signals Scout 健康与性能评估指南：基于运行窗口的五维诊断法

BrewUI：为Homebrew包管理器打造的开源图形界面工具

数字集成电路期末复习：题型背后的三大核心能力图谱

更多资讯

区块链运营计划书：从链上假设到可验证闭环

ERP信息化实施方案：从数据准备到系统切换的完整路径

AI Agent 驱动 Unity 命令行编译与自动化测试的完整实践指南

通达信真实资金流指标源码与实战应用指南

MiroFish多智能体仿真：群体智能预测引擎拆解与实战

BrewUI 图形化指南：让 macOS 包管理器 Homebrew 不再吓人

今日更新

校园网认证计费模式详解：AAA与代拨架构、原理及排障

Spring Boot+Vue垃圾分类毕设：分层、权限与排错实战

把 Cline 的 Base URL 改到 TaoToken 之后，DeepSeek 仍能修调试配置

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？