★ FEATURED ARTICLE 1. 先搞清楚 DFP 在整条工具链里到底占什么位置STM32 芯片支持包DFPDevice Family Pack安装与排错这件事看起来像点几下鼠标的小活但真正在项目里卡住人的往往就是它。我见过太多次这样的场面代码在别人机器上编译得干干净净换一台电脑打开工程一编译满屏红字一烧录报 No Algorithm found调试时外设窗口空空如也。这三类症状有相当一部分根源不在代码而在于 DFP 没装、装错版本、装了一半、或者装了但工程没真正引用上。DFP 是 CMSIS-Pack 体系里的一种包专门描述某一个芯片家族在工具链里的物理事实这颗芯片有哪些型号、Flash 和 RAM 从哪个地址开始有多大、启动文件长什么样、寄存器头文件叫什么、烧录时用哪段算法代码、调试时外设寄存器怎么解析。它不提供业务逻辑也不提供 HAL 或标准外设库那类软件框架但缺了它编译器不知道你的芯片有多少中断、链接器不知道内存边界、下载器不知道该怎么擦写 Flash。所以它更像一张身份证 户型图工具链靠它认识你手上这颗芯片。这篇内容适合三类人看刚接触 MDK 环境、还在为装了包怎么还是编译不过发愁的新手手上同时维护好几个芯片系列、被多版本包折磨的中级开发者以及需要给团队搭一套可复现开发环境的人。下面我按包是什么、里面有什么、怎么装、装完怎么验、坏了怎么修的顺序讲中间穿插参数计算和踩坑记录能直接照着做的部分我会给出具体路径和配置。1.1 从 MDK5 的架构变化说起理解为什么必须装包早年间用 MDK4 的时候器件支持是内置的安装包里自带一大堆厂商的设备数据库选型时从下拉框里挑就行头文件、启动文件、烧录算法全都躺在安装目录里。这套做法的问题很明显——芯片型号更新太快工具链一年发一版根本追不上每次新增一个系列就得等下一个大版本。MDK5 之后改成了外挂式内核、编译器、调试器这些引擎保留在主程序里而具体芯片的描述信息全部拆成独立的 Pack通过 Pack Installer 在线拉取或者离线导入。这个改动带来的直接好处是器件支持可以独立更新你不用重装整个 IDE 就能用上刚发布三个月的新型号代价是把环境完整性这件事的责任转移给了开发者——装没装、装哪个版本、工程引用的是哪个版本全得自己管。理解这一点之后很多现象就好解释了。为什么新电脑上打开老工程会报一堆找不到器件的错因为工程里记录了它当年用的器件名和组件版本而这台机器上压根没有对应的包。为什么同一个工程在两台机器上烧录表现不一样因为两边装的 DFP 版本不同连带的烧录算法文件也可能不同。这些都不是玄学是包管理没对齐。1.2 一个 DFP 包在磁盘上到底长什么样不管是线上下载还是离线导入最终落地的都是一个目录结构大致如下以某个 Cortex-M4 系列为例具体名字随系列变化Keil.系列_DFP.主版本.次版本.修订/ ├── CMSIS/ │ └── Flash/ │ ├── 系列_512.FLM │ └── 系列_1M.FLM ├── Device/ │ ├── Include/ │ │ ├── 系列xx.h │ │ └── system_系列xx.h │ └── Source/ │ └── ARM/ │ ├── startup_型号xx.s │ └── system_系列xx.c ├── 系列.svd ├── Keil.系列_DFP.pdsc └── .Web/ 或 .Download/几个关键点值得单独说。这个目录的上一层是厂商名再上一层是 PACK 根目录工具链启动时会扫描根目录下所有*.pdsc文件建立索引所以手动往目录里塞文件是有可能被识别的但前提是 pdsc 里的路径声明和实际文件位置严格对应差一个字符就索引不到。而.FLM文件不是普通数据文件它是编译好的可执行代码会被调试器在运行时加载进芯片 RAM 里执行用来完成擦除和写入。系列.svd是外设寄存器描述调试时 Peripherals 或 System Viewer 窗口的内容全靠它。Device/Include下是寄存器定义头文件Device/Source/ARM下是启动汇编和系统初始化。这四类东西加上 pdsc 索引基本就是 DFP 的全部价值所在——后面排错时我会反复回到这个目录结构来定位问题。提示如果你不确定当前机器上的 PACK 根目录在哪打开 Pack Installer从文件菜单里能看到实际的 Packs Root 路径。这个路径在不同版本、不同安装方式下可能不一样排查我明明装了却找不到的问题时第一步永远是先确认这个路径。2. DFP 包里四大关键资产逐个拆解装包只是手段真正决定工程能不能跑起来的是包里的具体资产有没有被正确使用。这一章我把四类资产拆开讲每类都说明它解决什么问题、配置错了会以什么形式报错。2.1 设备头文件与系统初始化文件编译期的基础设施Device/Include下的那个系列xx.h是整棵头文件树的根。它的典型内容是按外设分组的寄存器结构体定义、位域宏、基地址宏以及一堆#include语句——其中最关键的一条是包含内核头文件比如core_cm4.h因为 NVIC、SysTick、SCB 这些内核外设的定义并不在这个文件里。这就引出了第一个高频坑core_cm4.h不在 DFP 里它在 CMSIS Core 包里。很多人编译时看到cannot open source input file core_cm4.h第一反应是 DFP 装坏了重装一遍还是报错。实际上这是 ARM 的 CMSIS 基础包没装或者装了但工程没在 Run-Time Environment 里勾选 CMSIS CORE 组件导致包含路径没被自动加进去。system_系列xx.c负责在进 main 之前把时钟树、Flash 等待周期、向量表偏移这些底层配置好。这个文件的默认版本通常把系统时钟配到一个保守值实际项目里一般要按自己的晶振和倍频参数改。我一般会先确认这个文件里的外部晶振宏定义类似HSE_VALUE和板子上焊的晶振一致不一致的话串口波特率会整体偏移这种问题查起来极其费劲因为现象是串口能通但全是乱码很容易被误判成硬件问题。2.2 启动文件后缀选错程序直接跑飞Device/Source/ARM下通常会有多个启动文件命名规则是startup_系列容量标识xx.s。这里的容量标识和中断向量表规模直接挂钩——小容量、中容量、大容量型号的中断源数量不同向量表长度就不同。选错启动文件的后果非常典型程序能下载进去一上电就进 HardFault或者在使能某个外设中断时直接跳飞。原因是向量表里对应位置是空的或者放的是别人的中断服务函数地址。我遇到过一次工程从一个小容量型号复制过来改的启动文件忘了换结果只要一开串口接收中断就死机查了两天才定位到向量表错位。现在的趋势是用 RTE 组件自动挂载启动文件勾选 Device 下的 Startup 组件时工具链会根据你在 Device 页选的型号自动挑对应的汇编文件这比手动添加可靠得多。如果你坚持手动管理工程文件务必对照数据手册确认型号属于哪个容量档。2.3 FLM 烧录算法下载失败的第一嫌疑对象.FLM文件是整个包里最容易被忽视、也最容易出问题的部分。它的作用是在调试器连接上芯片后被临时加载到芯片 SRAM 的某个区域执行完成 Flash 解锁、页擦除、写入、校验这一整套动作。算法文件按 Flash 容量分档比如 512K 版和 1M 版覆盖的地址范围不同。工程里配置烧录算法时等于是告诉调试器在这个地址区间内用这段代码去操作 Flash。如果你的芯片实际是 1M Flash而工程里只挂了覆盖前 512K 的算法那么往 0x08080000 之后的地址烧写时就会报找不到算法反过来挂了 1M 算法但芯片只有 512K通常不会立刻报错但擦除操作可能触及不存在的区域导致超时。算法运行需要一块 RAM这个参数在 Flash Download 配置页里叫 RAM for Algorithm包含起始地址和大小。默认值一般是 0x20000000、0x1000 或 0x2000对大多数情况够用。但如果你的工程把这块 RAM 区域挪作他用比如做了 bootloader 共享内存或者链接脚本里把栈放在最前面算法加载时就会和用户数据打架报出 Cannot Load Flash Programming Algorithm 这类错误。这个参数我第一次遇到时完全没意识到它和链接脚本有关后来才想明白算法是在芯片复位状态下运行的它用的 RAM 地址必须避开任何可能被初始化的区域同时要在芯片实际 SRAM 范围内。注意Flash Download 的算法配置在 Debug 页和 Utilities 页各有一份。Debug 页决定调试会话启动时的烧录行为Utilities 页决定点下载按钮时的行为。两处不一致是极隐蔽的坑——现象是调试能跑、单独下载就失败或者反过来。改配置时我习惯两处对照着改。2.4 SVD 外设描述文件调试窗口的命根子SVD 是一份 XML把每个外设的寄存器偏移、位域名称、读写属性、复位值都描述清楚。调试器连上芯片后读内存再拿 SVD 去解释这些内存值于是你在窗口里看到的不再是一串十六进制数而是USART1 的 CR1 寄存器里 TE 位是 1这种可读信息。SVD 缺失或者版本和芯片对不上表现是外设窗口要么空白要么显示一堆无名寄存器要么名字对得上但位域偏移全错。最后一种最坑因为你会基于错误的位定义去判断问题越查越远。我现在的习惯是新拿到一个系列先随便使能一个外设打开外设窗口看一眼寄存器名和手册对不对对不上就先怀疑 SVD。SVD 一般是随 DFP 自动关联的选中器件后工具链会自己找到对应文件。如果你手动改过工程配置或者从别处拷来了 pdsc关联可能断掉。这时候需要在外设描述相关的设置里重新指定路径。3. 安装前的选型与准备工作很多人装包失败不是因为操作错而是因为一开始就选错了版本。这一章讲清楚版本之间的依赖关系以及装之前的几个前置条件。3.1 DFP、CMSIS、工具链三者的版本匹配这三个东西有明确的依赖链工具链版本决定它能解析哪个版本的 pdsc 格式DFP 的 pdsc 里会声明它需要的最低 CMSIS Core 版本而 CMSIS Core 又可能要求工具链达到某个版本。任何一环不满足要么装不上要么装上后行为异常。实际操作中最常见的是包太新从官网下了最新版 DFP导进一个几年前的工具链提示不兼容。这时候要么升级工具链要么回退到与该工具链匹配的 DFP 版本。我的建议是优先回退包版本而不是升级工具链——工具链升级可能带来编译器版本变化老工程里那些依赖特定优化行为的代码可能出现新问题牵连面太大。反过来包太旧也有问题。老版本 DFP 可能缺少某些新型号的描述或者 SVD 有已知错误。判断方法很简单在器件列表里搜你的完整型号搜不到就是包覆盖不到搜到了但外设窗口显示异常就怀疑 SVD 版本。现象大概率原因处理方向导入时提示包与当前工具链不兼容DFP 要求的最低工具链版本高于当前回退 DFP 版本或评估升级工具链的代价器件列表搜不到目标型号DFP 版本过旧未收录该型号升级到包含该型号的 DFP 版本编译报找不到内核头文件CMSIS Core 包缺失或未在 RTE 中勾选补装 CMSIS 包并在 RTE 勾选 CORE外设窗口寄存器名和手册对不上SVD 版本与芯片不符更换 DFP 版本或单独替换 SVD3.2 在线安装与离线安装各自适合什么场景在线安装的好处是省事在 Pack Installer 里找到对应系列点安装就开始拉取还能看到更新提示。缺点是受网络环境影响大包体动辄几十上百兆中途断了可能留下不完整状态。离线安装适合几种情况开发机和生产工位网络受限需要给多台机器部署完全一致的环境或者需要精确锁定某个历史版本在线列表里旧版本可能已经下架。离线包一般是一个.pack后缀的文件本质上是个压缩包通过 Pack Installer 的导入功能装进去。这里有个细节值得说不要图省事直接把 .pack 解压到 PACK 目录。虽然结构上确实能对上但缺少安装过程中的版本登记某些工具链在解析组件依赖时可能找不到记录表现为包明明在目录里RTE 里就是勾不上。老老实实走导入流程省下来的时间远比排查这个玄学问题的时间少。3.3 目录与权限几个容易被忽略的前置条件PACK 根目录的路径尽量全英文、不带空格。这不是迷信是实践中反复验证过的部分工具在解析路径时对非 ASCII 字符处理不严谨表现出来是包能装上但索引不全或者编译时某些相对路径拼错。我一般在装机第一步就把 PACK 目录指到一个短路径下比如根目录下的一个纯英文文件夹后续所有包都装在那里迁移环境时整目录拷走就行。权限问题也常见。如果工具链装在系统盘的程序目录下而 PACK 根目录也在那里面某些操作系统的权限控制会导致写入失败。表现是安装进度条走完了但目录里文件不全或者重启后又提示未安装。解决办法是把 PACK 根目录指到用户目录下的位置避开权限限制。磁盘空间要留够。一个中等规模的系列 DFP 加上配套的 CMSIS 包几百兆很正常如果同时装好几个系列上 G 也不奇怪。PACK 根目录所在的盘至少留出几 G 余量装到一半空间不足导致包损坏的情况我也见过。4. 完整安装与工程配置实操前面铺垫完了这一章给可直接照做的流程。我按装包—建工程—验证三段走。4.1 在线安装的完整步骤与过程记录打开 Pack Installer左侧是厂商和系列树右侧是选中项的详情。找到你的目标系列后右侧会列出该系列的多个版本选一个和你工具链匹配的不确定就选比最新版低一到两个小版本的稳点安装。安装过程中能观察到几件事进度条走的其实是下载加解压两步网络慢的时候会长时间停在同一百分比装完后左侧对应项前面会出现已安装的标记右侧版本列表里该版本会显示为当前版本。这时候别急着关窗口先在器件列表里搜一下目标型号能搜到说明索引建立成功了。我一般会同时把 CMSIS 基础包一起装好。虽然有些 DFP 会带上必要的内核文件但版本可能偏旧单独装一个较新的 CMSIS 包能让内核相关的组件更完整。装的时候注意看 CMSIS 包的版本是否被 DFP 的依赖声明接受装完再回头看 DFP 的状态有没有变成依赖不满足。4.2 离线 .pack 文件的导入方式拿到.pack文件后在 Pack Installer 的文件菜单里选导入定位到文件确认。导入过程比在线安装快因为不需要下载但同样会做解压和索引登记。导入后要确认两件事一是版本号显示正确二是器件列表能搜到。如果导入成功但器件搜不到多半是 pdsc 索引没刷新——关掉工程重新打开或者在 Pack Installer 里做一次刷新操作通常就能解决。有个实际场景值得提醒给产线或者实验室的多台机器部署环境时我会把整个 PACK 根目录打包连同工程一起分发。接收方把这个目录放到约定位置然后在 Pack Installer 里把 Packs Root 指过去省去逐台安装的麻烦。前提是路径结构一致且对方工具链版本与包兼容。4.3 新建工程时的器件、RTE 与调试器配置新建工程时第一步是选器件。这里不要图快把完整型号选准——同一个系列里不同容量档的 Flash 大小、中断向量数量都不一样。选中后窗口下方一般会显示这个器件来自哪个包、哪个版本这个信息记下来后面排查版本问题时有用。第二步是 Run-Time Environment 配置。至少勾三项CMSIS 下的 CORE提供内核头文件和启动所需的基础、Device 下的 Startup启动汇编、以及你实际用到的外设驱动如果用标准外设库的话。勾选时注意看右侧的依赖提示有红色标记说明有未满足的依赖别硬着头皮点确定。第三步是调试器配置。在调试选项里选对调试器类型进入设置后确认 SWD 或 JTAG 接口速率合理初次调试用低速更稳、Flash Download 页里算法覆盖的地址范围与芯片实际 Flash 大小匹配、RAM for Algorithm 的地址和大小不与程序冲突。Utilities 页里勾选使用调试驱动并确认这里的算法配置和 Debug 页一致。4.4 三步验证安装是否真正生效装完不等于生效我固定做三步验证。第一步编译一个最小工程只包含启动文件和 main 里一个死循环。能编译通过说明头文件路径和启动文件都挂上了。这一步失败基本就是 CMSIS 或者 DFP 引用问题。第二步下载并运行。能下载进去并停在 main 的断点说明烧录算法、调试器配置、芯片连接都正常。这一步失败要区分是算法问题还是硬件连接问题区分方法是看报错文字算法相关通常是 No Algorithm found 或 Cannot Load Flash Programming Algorithm连接相关通常是访问目标失败或识别不到器件。第三步开外设窗口随便使能一个外设比如点亮一个 GPIO看寄存器窗口里的值是否随代码变化。如果窗口空白或者寄存器名明显不对说明 SVD 没生效。三步全过这个 DFP 在你的环境里才算真正可用。少做一步后面可能就是几小时的排查。5. 高频故障排查实录这一章按症状分类每个症状给出定位路径。我的习惯是从最外层往最里层查先确认包在不在、版本对不对再确认工程有没有真的引用上最后才怀疑芯片和硬件。5.1 器件列表里搜不到目标型号先确认包装了没有、装的是哪个版本。在 Pack Installer 里搜系列名看已安装版本列表。如果压根没装装就是了。如果装了但搜不到型号说明这个版本的 DFP 还没收录这颗料——尤其是新发布的型号从流片到进包有滞后。还有一种情况是型号写法差异。同一个芯片可能有多种命名后缀封装、温度等级不同搜索时用系列前缀加容量标识更容易命中比如只搜前面几位。另外注意器件列表里显示的可能是系列名 型号的组合形式直接搜完整料号有时反而不匹配。如果确认包是对的、型号确实在里面但工程里的下拉框就是没有那可能是工程文件里记录的器件名和当前包里的名字不完全一致比如包升级后器件名有微调。这种情况新建一个工程选一遍器件对比两个工程配置文件里的器件字段能快速定位差异。5.2 编译期找不到头文件这是最高频的问题但原因分好几种得看具体缺的是哪个文件。缺core_cm4.h这类内核头文件问题在 CMSIS 基础包不在 DFP。检查 CMSIS 包是否安装、RTE 里 CMSIS CORE 是否勾选。如果勾了还找不到看工程的头文件包含路径里有没有自动加上 CMSIS 的 Include 目录有时候 RTE 配置正确但路径没同步手动补一下即可。缺stm32f4xx.h这类器件头文件问题在 DFP 或者包含路径。检查 Device/Include 目录是否存在、工程路径是否指向它。如果目录在但编译还找不到可能是路径里带了中文或空格工具链解析失败。缺system_stm32f4xx.h说明 Source 目录没被正确引用或者这个文件被手动挪了位置。RTE 挂载启动组件时通常会自动带上系统初始化文件手动管理工程的话要自己确认文件在工程树里。还有一种隐蔽情况多个版本的 DFP 同时存在工程引用的路径指向旧版本目录而那个目录已经被清理掉了。表现是路径看起来对实际文件不存在。这时候把工程里的器件重新选一遍让工具链重写路径最省事。5.3 No Algorithm found 与 Flash Download failed这两个报错经常一起出现但根因可能不同。No Algorithm found for: 08000000H - 0800FFFFH 的意思是调试器要在 0x08000000 到 0x0800FFFF 这个区间内写数据但当前配置的算法没有覆盖这段地址。排查顺序是先看芯片实际 Flash 大小查数据手册再看 Flash Download 页里挂的算法覆盖范围。常见错误是芯片是 1M 的却只挂了 512K 算法或者反过来算法挂了但地址范围参数被改过。Cannot Load Flash Programming Algorithm 更偏向算法本身的加载失败常见原因有三个算法文件路径失效包被移动或删除、RAM for Algorithm 参数不合理地址超出 SRAM 范围或与程序占用的区域重叠、芯片处于某种特殊状态比如读保护未解除、处于低功耗模式没被唤醒。我遇到过一例算法参数里 RAM 起始地址被改成了 0x10000000那是外设区算法加载进去直接跑飞报的就是这个错。还有一种情况报 Flash Download failed - Target DLL has been cancelled这个通常不是算法问题而是下载过程中被中断供电不稳、SWD 速率过高、复位方式配置不对比如选了硬件复位但复位脚没接。诊断办法是把速率降到最低、把复位方式改成软复位或者不复位逐个排除。实操心得把 Options for Target 里 Debug 页和 Utilities 页的 Flash Download 配置截图存一份出问题时对照着看。这两页的配置项长得几乎一样改了一处忘了另一处的情况太常见了。5.4 外设窗口一片空白或者寄存器名全错先确认 SVD 有没有被正确关联。选器件的时候工具链通常会自动关联但如果工程是从别处拷来的或者手动改过工程配置关联可能丢失。可以在工程配置里找到外设描述相关项看路径是否为空或指向不存在的文件。如果路径正常但窗口还是空的检查调试会话有没有真正连上芯片。外设窗口的数据是运行时从芯片内存读出来的连不上自然什么都读不到。这种情况下编译和下载可能都正常因为它们走的是不同流程唯独外设窗口空容易被误判成 SVD 问题。寄存器名对得上但位定义明显错误那是 SVD 版本和芯片不匹配。这种情况只能换 DFP 版本或者在包目录里找到 SVD 文件和手册的寄存器映射表逐项核对几个关键外设确认偏差点。我一般核三个GPIO 的模式寄存器、USART 的控制寄存器、RCC 的时钟使能寄存器这三个的位定义最能暴露版本问题。5.5 多版本共存引发的诡异现象PACK 目录里同时躺着同一个系列的多个版本是很多诡异问题的根源。工具链的索引机制通常以 pdsc 里的版本号为准但工程引用可能有自己的记录两边不一致时就会出问题编译用的是新版本头文件链接用的是旧版本的某个库结果是编译能过、运行异常。我的做法是一个系列在同一台机器上只保留一个版本。需要对比版本行为时用另一个 PACK 根目录通过环境配置切换而不是让两个版本挤在同一个目录里。虽然工具链理论上是按版本号隔离的但实践中出过太多次意外不值得冒这个险。清理旧版本时用 Pack Installer 的移除功能别手动删目录。手动删容易留下索引残留下次扫描时可能报出包已损坏之类的提示。5.6 常见问题速查表报错/现象优先检查常见处理导入包提示版本不兼容工具链版本与 pdsc 声明的最低版本回退 DFP 版本器件下拉框无目标型号包是否安装、版本是否覆盖该型号升级或补装对应系列 DFP找不到 core_cm4.hCMSIS 基础包与 RTE 中的 CORE 组件补装 CMSIS 包并勾选 CORE找不到器件头文件DFP 的 Device/Include 是否被加入路径重新选器件让工具链重写路径No Algorithm found算法覆盖范围与芯片 Flash 大小挂载覆盖全片容量的 FLMCannot Load Flash Programming AlgorithmRAM for Algorithm 地址与大小改为 0x20000000 起、0x1000 到 0x2000调试可用但单独下载失败Utilities 页与 Debug 页配置不一致两处算法配置对齐外设窗口空白SVD 关联与调试会话状态重新选器件或检查 SVD 路径寄存器位定义错误SVD 与芯片型号匹配度更换 DFP 版本上电必进 HardFault启动文件与容量档是否匹配换成对应容量的启动汇编6. 我踩过的坑与长期维护习惯排错能力再强也不如一开始就不出问题。这一章讲讲我怎么把 DFP 这层环境管起来。6.1 团队内统一版本的做法多人协作时最大的麻烦是你的包和我的包不一样。我推行过一套很土但有效的办法在工程仓库根目录放一个环境说明文件写清楚工具链版本、DFP 完整版本号、CMSIS 包版本号以及一个离线包集合的存放位置。新成员入职先照着这个文件把环境配齐再拉代码。更进一步把离线包文件本身也纳入版本管理如果仓库容量允许。这样即便官网上的旧版本下架了团队内部还能复现当年的构建环境。这一点在做长期维护的项目上价值极大——两年后要修一个老产品的 bug环境能一模一样地搭起来省下的是几天时间。RTE 组件版本也要固定下来。组件勾选后会记录版本号如果允许自动用最新版本那么包一升级工程引用可能就变了。我的习惯是把这个自动升级的选项关掉升级包版本时手动确认并提交工程文件变更让版本变化成为一次有意识的、可追溯的操作。6.2 环境迁移与备份的具体做法换机器或者重装系统时最省事的迁移方式是整目录拷贝 PACK 根目录加工程文件。拷过去之后把工具的 Packs Root 指到新位置打开工程验证三步编译、下载、外设窗口一般就完事了。如果新机器上的路径和旧机器不同工程文件里记录的绝对路径可能失效。这种情况重新选一遍器件让工具链重写路径即可但要注意重选之后检查 RTE 组件有没有被动过——少数情况下重新选器件会重置组件勾选。备份策略上我一般保留两套环境一套是当前主线包版本较新一套是归档环境装着历史项目用过的所有老版本包单独的 PACK 根目录平时不碰。归档环境的目录名里带上日期方便回溯。最后分享一个我觉得特别值的小习惯每次遇到一个新的报错把报错原文、当时的包版本、工具链版本、解决办法记到一个自己的问题库里。这些东西官网文档不会写社区里搜到的答案也经常语境不对。攒上一年你会发现排错速度完全不是一个量级——因为大部分问题你都见过剩下的那部分你也知道该从哪里入手查。这个清单我一直在维护最新的几条已经细化到了具体的算法参数范围。环境这种事情平时多花十分钟沉淀关键时刻少熬两个通宵。
阅读完成 · 觉得有帮助？
在正式发放前改掉了)
