如果你在调试 ACPI 设备树时碰见过Device (PCI0)被枚举出来又看到注释里写着“this device have a _HID of PNP0A03”并且顺着代码追到了一个叫IsPciDeviceWorker的内部函数那么你多半正在跟 PCI 设备识别逻辑较劲。这篇东西就是围绕PCI0 / PNP0A03 / IsPciDeviceWorker这条线索展开的把“怎么判断一个 ACPI 节点是不是 PCI 设备”这件事拆开揉碎讲清楚。先说结论在 ACPI 世界里PCI 根桥不是靠名字里带不带 “PCI” 三个字母来认的而是靠_HID返回的硬件 ID 来认。Device (PCI0)之所以被判定为 PCI 设备原因就是它的_HID是PNP0A03这个 ID 在 ACPI 规范里专门分配给 PCI root bridge。而ACPI!IsPciDeviceWorker这类函数本质上是把“这个 Device 对象的 HID 是否匹配已知 PCI 设备 ID”以及“父设备链路”这些条件做成了可复用的判断入口方便设备枚举、资源分配、电源管理各个模块统一调用。整篇文章会从 ACPI 的设备描述方式讲起拆解_HID的语义分析IsPciDeviceWorker内部可能的判断分支再结合调试实战给出误判排查方法很适合正在啃 ACPI 表解析、BIOS 固件开发、嵌入式平台 BSP 移植或者操作系统内核设备枚举的同学参考。1. 背景ACPI 是如何描述 PCI0 这个设备的在接触 Windows 内核调试、Linux ACPI 子系统或者 UEFI 固件代码之前很多人对 ACPI 的认知停留在“电源管理”这个层面觉得 ACPI 只是管睡眠唤醒的。实际上 ACPI 对于操作系统更重要的职责是“设备发现”它用一张张表DSDT、SSDT描述系统里存在哪些硬件以及这些硬件如何接入中断、如何映射地址空间。这张表不是给人读的而是给操作系统解析的里面全是 Device 定义、方法定义和资源描述。拿 PCI 总线来说x86 平台上最常见的 PCI 根桥就是\_SB_.PCI0这个对象。它在 DSDT 里长什么样呢大致是这样一个片段Device (\_SB_.PCI0) { Name (_HID, EisaId (PNP0A03)) Name (_ADR, 0x00) Name (_BBN, 0x00) Device (P0P1) { ... } }这里有几个关键的量_HIDHardware ID告诉操作系统这个设备是什么字符串格式通常是 EISA ID 或者 PCI Vendor/Device ID 组合。_ADRAddress对于 PCI 设备来说表示它在父总线上的 Device 号和 Function 号根桥一般就是 0。_BBNBase Bus Number表示这个桥的次级总线号从几开始PCI0 如果直接接在总线 0 后面_BBN就是 0。_UIDUnique ID当同型号设备有多个实例时用来区分PCI0 和 PCI1 就是靠这个区分的。Device (PCI0)这个名字本身完全是操作系统约定俗成ACPI 机器语言不要求你叫 PCI0你叫PCI_ROOT、RP01、PCIEX都行OS 识别它靠的是_HID。这也是为什么代码里判断 PCI 设备不能靠名字匹配必须靠 HID 或者父链逻辑。PNP0A03这个 ID 在 ACPI 规范里是标准化的。它表示“PCI Root Bridge”即一个直接挂在系统总线上的 PCI 根桥。只要 ACPI 表里有 Device 对象的_HID等于PNP0A03操作系统就会把它当作一条 PCI 总线层次结构的起点进而扫描总线上的设备挂接驱动分配资源。搞清楚这个背景之后再回头看那句注释“this device have a _HID of PNP0A03”就清楚多了它是在给后续判断做铺垫说明某个函数走到这里的时候已经确定当前节点是 PCI 设备了因为 HID 已经命中。而IsPciDeviceWorker这个名字里的 Worker 后缀表明这是一个被调度的底层工作函数不是对外接口——外层可能还有一个IsPciDevice负责从设备对象里提取 HID、SEG、BBN 这些信息然后传给 Worker 去做具体比较。2. 解开 IsPciDeviceWorker 的判断条件源码注释背后的逻辑在没有贴完整函数代码的情况下我们可以从函数名、注释和 ACPI 规范反推IsPciDeviceWorker内部到底做了什么。绝大多数内核代码里“判断某 ACPI 节点是不是 PCI 设备”这个逻辑会拆成几个层次来处理。第一层看当前 Device Node 的 HID 是否命中 PCI Root Bridge 的 ID。这里至少要匹配两个值PNP0A03和PNP0A08。PNP0A03是传统 PCI 根桥PNP0A08是 PCI Express 根桥。如果只匹配PNP0A03那么 PCIe 根桥就会被漏掉设备枚举就会出问题。所以正规实现在注释里写PNP0A03只是一个示例实际代码大概率会同时检查这两个值。第二层有些 PCI 设备并没有 HID尤其是 PCI 总线上的子设备比如一个声卡、一个 USB 控制器。它们在 ACPI 表里的_ADR是用来告诉 OS 它们在 PCI 总线上的位置的但_HID不一定是 PNP ID。那怎么办判断逻辑不能只看当前节点还需要看父链如果一个 ACPI 节点的父设备是 PCI 根桥或 PCI 桥那么它自己也应该被归类为 PCI 设备因为它的地址空间、中断路由都挂在 PCI 总线上。这种“向上回溯”的判断典型代码如下static bool IsPciDeviceWorker(ACPI_HANDLE handle, bool bRecursive) { ACPI_DEVICE_INFO *info; AcpiGetObjectInfo(handle, info); if (ACPI_SUCCESS(AcpiGetObjectInfo(handle, info))) { if ((info-Flags ACPI_PCI_ROOT_BRIDGE) || (info-HardwareId.String (strcmp(info-HardwareId.String, PNP0A03) 0 || strcmp(info-HardwareId.String, PNP0A08) 0))) return true; } ... }这里有一个很容易被忽略的细节EisaId宏生成的字符串。在 ASL 里EisaId(PNP0A03)会被编码成一个 32 位整数等到操作系统解析时这个整数会被转换回字符串PNP0A03。但如果固件代码里直接写Name (_HID, PNP0A03)虽然字符串本身就是PNP0A03可某些 ACPI 实现会把它按“兼容 ID”而不是“硬件 ID”来处理导致判断失效。这也是很多平台出现“设备节点没有被识别为 PCI 设备”的一类根因。第三层有些 PCIe Root Port比如\_SB_.PCI0.RP01这样的对象的父节点不是 PCI 根桥的直属子节点但它们本身具备了_ADR并且通过_OSC协商了 PCIe 能力。这种情况下IsPciDeviceWorker可能要结合_SEGPCI Segment Group来判断或者检查它的父设备是否是PNP0A08。总之“PCI 设备”在 ACPI 里不止一个画像根桥有 HID桥后面的设备有 ADR再往后走还有可能出现在 _DSM 方法里。把这些画像串起来的工作函数就是我们标题里看到的 Worker 函数。最后还有一个常见分支是处理热插拔控制器PCI Hotplug Controller。很多 ACPI 节点描述的是插槽本身比如\_SB_.PCI0.SLOT0。这类节点是否有自己的 HID有可能没有或者只有一个笼统的PNP0C0FPCI interrupt link 设备。那么要判断它是不是 PCI 设备单靠 HID 就不够了。此时注释里写的“判断 PCI 设备的条件”还应该包括“父设备是 PCI 桥且这个节点有 _ADR”。也就是说这个 Worker 大概率是多个条件 OR 起来的结果。我把这个判断逻辑整理成一张表判断路径依据典型节点命中后含义HID 精确匹配_HIDPNP0A03\_SB_.PCI0传统 PCI 根桥HID 精确匹配_HIDPNP0A08\_SB_.PCI0PCIe 根桥兼容 ID 匹配父设备 HID 是PNP0A03/PNP0A08PCI0.RP01、PCI0.HUB0PCI 总线上的桥设备ADR 有效父设备是 PCI 桥且自身有_ADRPCI0.SLOT0挂载在 PCI 总线上的设备资源模板匹配父设备有_CRS且包含总线资源某些没有 HID 的 PCIe 端口节点参与 PCI 资源分配这也是为什么注释里说“this device have a _HID of PNP0A03”只是一个充分条件并不是全部条件。3. 为什么 PNP0A03 可以写成大写、小写、甚至省略尾字符都不行很多刚接触 ACPI 编码的人会问一个问题字符串比较不就是 strcmp 吗ASCII 字符集里 PNP0A03 和 PNP0a03 有什么关系严格来说ACPI 命名空间里的字符串比较是区分大小写的规范里定义的 ID 也是定长大写。但在操作系统实现里为了兼容各种畸形 ACPI 表很多代码会进行大小写不敏感的比较。IsPciDeviceWorker如果直接用 strcmp遇到 OEM 把_HID写成PNP0a03的情况就会误判成非 PCI 设备。这可不是杞人忧天。有不少主板 DSDT 里的_HID是手工编出来的编译 ASL 的编译器通常会把EisaId宏正确编码但一些被魔改的 DSDT 会直接把字符串PNP0A03写成PNP0A3、PNP0A03前后带空格甚至PNP0A003。这些错误在 Windows 下可能被容忍因为 Windows 的 ACPI 驱动有一套宽松匹配但如果你自己写的 Worker 函数只做严格匹配就会列入“非 PCI 设备”分支导致后续资源分配不执行。遇到这种坑正确的做法是在比较前先对字符串做标准化处理去掉首尾空白把字母统一转为大写再去跟PNP0A03、PNP0A08比较。像这样#define ACPI_HID_PNP0A03 PNP0A03 #define ACPI_HID_PNP0A08 PNP0A08 static bool IsAcpiHidEqual(ACPI_DEVICE_INFO *info, const char *hid) { char *p; if (info-HardwareId.String NULL) return false; p info-HardwareId.String; while (*p ) p; if (strncasecmp(p, hid, strlen(hid)) ! 0) return false; p strlen(hid); if (*p || *p \0) return true; return false; }另外还要注意ACPI_DEVICE_INFO结构体里的字段不是所有 ACPI 实现都有HardwareId.String这个成员。有些实现里是HardwareId.Value整数形式需要先调用AcpiExConvertToAscii之类的工具函数转成字符串再比较。这也是为什么绝大多数 Worker 函数不直接读字段而是调AcpiGetObjectInfo拿统一结构体的原因。如果在调试时看到明明 DSDT 里写的是Name (_HID, EisaId (PNP0A03))内存里读出来也是PNP0A03但IsPciDeviceWorker还是返回 false那就要检查是不是ACPI_DEVICE_INFO的Flags中没有设置ACPI_PCI_ROOT_BRIDGE。这个 Flags 是 ACPI 子系统在解析节点时根据 HID 自动打上的标志位如果底层没有正确识别 EisaId 编码Flags 就不会被设置。这种情况下IsPciDeviceWorker如果只查 Flags 而不再做字符串匹配就会误判。所以从实操角度总结判断条件不能只依赖一个字段最好 HID 字符串匹配和 Flags 检查二者取 OR。宁可宽松一点点也不要把 PCI 根桥漏掉因为漏掉一个 PCI0 意味着整条 PCI 总线树在 ACPI 层面不可见所有 PCI 设备的中断、电源管理、资源协调全部失效。4. 实操如何在调试器中验证 PCI0 的识别过程当你遇到问题——比如某个驱动加载失败、某个 PCIe 设备明明在总线上却枚举不到怀疑是 ACPI 把 PCI0 识别为非 PCI 设备——你需要的不是猜而是到调试器里把判断条件实际走一遍。第一步确认 DSDT 里的 PCI0 节点信息。在 Windows 内核调试环境中可以用 ACPI 调试扩展命令来查看设备对象!acpiinfo \_SB_.PCI0或者用!devobj查看设备对象扩展!devobj \Device\ACPI 0如果用的是 Linux 内核直接读/sys/firmware/acpi/tables/DSDT然后用iasl -d DSDT反编译搜索PNP0A03出现的位置。反编译结果能够直接看到 PCI0 节点下的_HID到底是什么值是字符串还是 EisaId 整数这个信息对判断 Worker 函数为什么走错分支非常关键。第二步给IsPciDeviceWorker下断点。如果你手上恰好有这个模块的符号可以在函数入口下一个断点查看传入的 handlers然后单步走。没符号也能断通过x列出ACPI!IsPciDeviceWorker如果列表为空说明函数是被静态内联进调用方了。这种情况就去查调用方看IsPciDevice或者AcpiIsPciDevice这类顶层函数。第三步检查传入 Node 的 HID。Worker 函数内部通常会有类似这样的逻辑通过AcpiGetObjectInfo拉取ACPI_DEVICE_INFO判断info-HardwareId.String判断info-Flags所以调试时要把断点下在两个位置AcpiGetObjectInfo返回之后和 HID 字符串比较指令之前。前者能看到info结构内容确认 HID 字段是否被填充后者能确认比较两边的值各是什么。在 windbg 里可以用dt ACPI!ACPI_DEVICE_INFO来查看结构体布局再用dS显示字符串。我踩过的一个典型坑是这样的某个平台在 DSDT 里给 PCI0 写的是Name (_HID, PNP0A08)而另一个版本固件写的是Name (_HID, EisaId (PNP0A08))。第一个版本因为字符串被编译器当作“非 EISA 格式 ID”存成了不带压缩的字符串某些内核模块在处理这种字符串时会把前两个字符当作 Vendor 码结果一直没匹配上。后来加了一个兼容分支对字符串形式直接比较才算过。这个经历让我养成了一个习惯反编译 DSDT 时凡是看到_HID下面跟的是字符串而不是 EisaId就要多留一个心眼判断函数里必须覆盖这种形式。第四步验证父链回溯逻辑。如果你的 PCI0 节点本身正确但它下面的子设备节点被 Worker 函数判为非 PCI 设备问题多半出在父设备判断上。IsPciDeviceWorker的递归判断通常有两层一层是看当前节点一层是看父节点。每个父节点的 HID 可能不同如果父节点的 HID 是某个自定义的 OEM ID比如NVDA0000、AMDI0030那即使父设备实际是 PCI 桥只匹配 PNP0A03 和 PNP0A08 也找不到。对这种平台需要在判断条件里补充“父节点的 Type 是 ACPI_TYPE_DEVICE 且父节点有 _ADR”作为兜底。调试实录里记录一个办法用递归打印函数把每个节点的 HID 和_ADR打印出来人工判断哪些节点实际上线了。下面这个伪代码思路很实用void DumpAcpiNodeParentChain(ACPI_HANDLE child) { ACPI_HANDLE parent child; while (parent) { ACPI_DEVICE_INFO *info; AcpiGetObjectInfo(parent, info); DbgPrint(Node%p HID%s ADR0x%llx Type%d Flags0x%x, parent, info-HardwareId.String, info-Address, info-Type, info-Flags); AcpiGetParent(parent, parent); } }把这条链打印出来以后对 Worker 为什么返回 true/false 就能一目了然。比如看到链上有一个节点的 HID 是PNP0C08ACPI 电源管理控制器而你要判断的 PCIe 端口正好挂在它下面那么如果 Worker 只看父 HID就会误判。这种层级设计不常见但确实是有些便携设备 OEM 会干的事。5. 常见误判场景与问题排查速查表为了让你在遇到具体报错时能快速定位我把实际项目中碰到过的IsPciDeviceWorker误判场景整理成一张速查表。这里的“症状”来自调试日志或设备枚举失败现象“可能原因”是从 Worker 判断条件的角度反推的“排查建议”是可直接落地的动作。症状可能原因排查建议ACPI 枚举日志中 PCI0 节点存在但被归类为非 PCI 设备_HID是字符串形式而不是 EisaIdWorker 只查 Flags 字段反编译 DSDT确认_HID写法调试时打印info-Flags和HardwareId.StringPCIe 根桥设备找不到但传统 PCI 根桥正常判定逻辑里只匹配了PNP0A03漏掉PNP0A08检查比较列表补上PNP0A08PCIe Root Port 下的设备枚举一半成功一半失败父设备链上存在非标准 HID如 OEM ID向上回溯中断打印父链 HID确认判断递归深度是否足够热插拔的 PCIe 卡枚举不到ACPI 节点只有_ADR没有_HID被当成普通 ACPI 设备增加“父设备是 PCI 桥且自身有 _ADR”的兜底判断系统启动时报 ACPI 资源冲突PCI 总线资源没有被保留Worker 返回 true 的设备太多了把非 PCI 设备也当成 PCI 根桥检查是否错误地把PNP0A06ISA I/O或PNP0A07System Board匹配进去了同一份固件在 Win10 正常、Win11 下异常新旧系统对_OSC处理差异PCIe 根桥做条件判断时依赖了_OSC返回状态打印_OSC返回值确认IsPciDeviceWorker是否被_OSC结果影响这里面最常见的坑就是把PNP0A06和PNP0A07加到判断列表里。PNP0A06是 ISA I/O 资源设备PNP0A07是主板资源设备它们和 PCI 根桥虽然前缀相似但语义完全不同。如果在做“PCI 设备识别”时用前缀匹配PNP0A0就会把这俩也圈进来导致系统把普通 I/O 端口当成 PCI 资源去分配轻则资源预留出错重则开机直接蓝屏或 panic。再分享一个我曾经遇到过的奇葩 case某个模拟器固件把 PCI0 的_HID写成了PNP0A03但_BBN写成了 3。按规范根桥的_BBN应该是 0表示根桥所在的 Segment 的总线号从 0 开始。IsPciDeviceWorker本来没检查_BBN只检查 HID所以识别是成功的。但当系统去扫描总线 0 和总线 3 的时候发现总线 0 上没有任何设备而 PCI0 声称自己管理的次级总线是 0跟实际不符。这个问题最终是通过修正_BBN解决的。这件事给我们的启发是Worker 返回 true 只是第一步后续枚举逻辑依赖的_BBN、_SEG也必须正确否则判断逻辑再严谨也难逃后续坑。6. 扩展应用这个判断逻辑除了识别 PCI0 还能做什么IsPciDeviceWorker只是 ACPI 子系统里众多设备判断函数之一。理解了它的设计思路你会发现整个 ACPI 设备管理的很多场景都是类似的套路。第一个场景是中断资源分配。系统在启动阶段需要知道哪些 PCI 设备需要分配中断向量哪些 ACPI 设备走的是固定中断。判断一个设备是 PCI 设备还是平台设备直接影响中断路由表的选择。PCI 设备的中断通过_PRT映射到 PCI 总线上的 Link Device平台设备则可能有自己的_PRS和_SRS。所以 Worker 函数的返回值会直接影响中断分配决策。如果你看到某些 PCIe 设备中断始终配不上回头检查一下这个函数是否把设备误判成了平台设备往往能找到根因。第二个场景是电源管理。现代操作系统在做设备电源状态转换时需要知道一个设备背后的电源管理对象属于哪个总线。PCI 设备的电源管理走的是 PCI-PM 或 ACPI 的_PSx方法而平台设备可能走的是_PR0/_PR3关联的电源资源。两者调用路径完全不同。IsPciDeviceWorker在这里的作用是帮助内核决定采用哪一套电源策略。第三个场景是设备路径转换。UEFI 启动后OS 需要把 UEFI 设备路径Device Path转换成 ACPI 路径或者反过来。这个转换过程中判断一个 ACPI 节点是不是 PCI 设备决定了路径节点是写PCI(0,0)还是ACPI(). 如果判断错了路径转换失败启动项定位就会出问题。其实很多人在做 UEFI 引导调试时遇到的神秘失败往下一追都可以追溯到某个 Worker 函数对 PCI 设备类型的判断不准确。理解了这三个场景你就明白为什么注释里要把“PNP0A03”单独拿出来说事——它不仅是 PCI0 的身份证也是整个 ACPI 设备路由体系里的一把钥匙。IsPciDeviceWorker返回 true 与否的每一点偏差都会在系统启动早期被放大成各种链路错误。所以写这类判断逻辑时要遵循一个原则在 HID 匹配的基础上宁可用多维判断HID、Flags、父链、ADR取并集也不要只用一个条件去一刀切。7. 实操心得几个值得写进代码注释的经验这段时间跟 ACPI 设备识别反复交手有几点经验值得沉淀下来。如果你也在写或者维护类似IsPciDeviceWorker的函数下面这些建议可以直接用。第一注释里写条件时要写全。标题里那句 “this device have a _HID of PNP0A03” 确实点出了核心但如果只是孤零零写这一句后人很容易误解成“只要 _HID 是 PNP0A03 就是 PCI 设备”。更好的注释写法是列出完整判断流程节点自身 HID 是否为PNP0A03/PNP0A08节点父设备是否包含ACPI_PCI_ROOT_BRIDGE标志节点是否在 PCI 根桥命名空间下且自身具备有效_ADR这样后人维护代码时不用通读整个函数体就能快速知道这个函数在干什么、哪些分支会被命中。第二比较 HID 前先做字符串标准化。前面提到的大小写、空格、字符串/整数形式问题最好的解决办法是写一个统一入口函数所有 ACPI HID 比较都走它。这个函数内部可以先用AcpiGetObjectInfo拿结构体再统一把HardwareId.String转为大写去空格然后比较。全系统统一入口比每个调用方各自写一套strcmp要可靠得多。第三Worker 函数不要直接暴露给驱动层。IsPciDeviceWorker带 Worker 后缀本身就说明它是内部函数。调用者应该经过一个带明显语义的公开接口比如AcpiIsPciDevice、PciIsDevicePresent。每个公开接口内部可以维护一个全局缓存比如把已经判断过的节点和结果放到 Lookaside 里第二次遇到同一个节点时直接返回缓存结果。ACPI 表解析阶段会有大量重复查询没有缓存的话性能会比较难看。我见过有些实现就是没加缓存启动时间被 ACPI 查询拖慢了一两秒后来加了哈希缓存后就正常了。第四注意函数的可测试性。设备节点的判断逻辑适合做成纯函数输入是一个ACPI_HANDLE输出是 boolean不依赖全局状态。如果你够条件可以在用户态写个小工具直接用 ACPICA 的用户态库加载 DSDT遍历所有节点跑一遍IsPciDeviceWorker把结果和已知硬件布局对比验证。这样不用反复重启真机就能发现判断条件写错的问题。第五善用 ACPI 表反编译工具。一次排查启动问题的过程里我用iasl -d DSDT反编译出 ACPI 源文件后再写一段小脚本把所有Device节点的_HID和父节点缩进打印出来一眼就能看出平台架构师在设计设备树时是否遵守了规范。这种工具链值得放进日常调试工具箱比每次都下调试器断点高效得多。8. 后续扩展把单个设备判断升级为设备树关系校验当 ACPI 设备数量增大比如服务器主板上挂了几十条 PCIe bus、几十个 Root Port、成百个 Slot单个IsPciDeviceWorker的返回值就不够了。我们需要的是设备树层面的关系校验PCI0 下挂的每个节点是不是都在逻辑上等价于 PCI 设备某个 ACIP 节点明明是PNP0C02主板保留资源却出现在 PCI0 下是不是 DSDT 写错了这种场景下IsPciDeviceWorker适合作为一个基础判断原子再往上叠加树遍历和一致性检查。比如写一个扫描函数遍历某个根节点下的所有子节点统计每个层级的设备类型打印出“非 PCI 设备出现在 PCI 桥下”的警告。这类扫描逻辑在 Windows 和 Linux 下都可以做只是 API 不同。做一次全局扫描后大部分 ACPI 表错误都能被暴露出来开发效率提升非常明显。如果你打算做这种校验从工程角度建议提前建好一个“已知设备类型表”至少有这几项HID 字符串设备类型PCI Root、PCI Bridge、内存设备、处理器、电源设备等允许出现在哪个父类型之下是否需要_ADR是否需要_BBN/_SEG在这个表的基础上校验逻辑就简化为查表加路径判断。后续固件升级时只要跑一遍校验就能快速确认新增的 ACPI 节点没有破坏既有判断逻辑。我自己在做一个跨平台项目的时候就是按照这个思路把IsPciDeviceWorker的判断逻辑搬到了用户态工具里然后用真实 DSDT 跑了一遍全树校验。结果发现一个从未在启动日志里暴露出来的问题某个设备节点同时出现在两个父节点下导致 Worker 在递归回溯时产生了歧义。这种情况如果只靠黑盒调试可能很久都定位不到。所以我的建议是不要满足于“能跑通”要把设备识别逻辑当成可测试的基础组件来看待。把每一次对PCI0 / PNP0A03的判断都变成可重复、可验证的单元这套逻辑才能真正成为你在 ACPI 开发里的底气。至于那行注释建议改成更有指引性的描述// PCI root bridge 的 _HID 是 PNP0A03传统 PCI或 PNP0A08PCIe。 // 判断 PCI 设备时先查 HID再查父链最后用 _ADR 兜底。 // 完整判断条件见 IsPciDeviceWorker 实现。简洁准确后人一眼就知道该看哪里。代码注释不一定要多长但一定要把“为什么这么判断”和“判断条件有哪些”讲清楚这才是有价值的注释。