占位库名称之后还有什么：CODESYS的解析结果与应用编译范围

PLC项目的库管理资料里出现一个占位名称，说明项目保存了一个标识，却还没有完整说明它最终对应哪份库。CODESYS《Command: Placeholders》将Name解释为占位标识，将Library解释为项目当前的解析结果。这两栏相邻，指向的内容却不同：前者使占位可被称呼，后者才继续联系具体项目中的库对象。

编译范围使这种关系更清楚。文档强调，编译总是面向一个具体应用，而库管理器中的条目需要有实际可用的库。一个项目可能涉及应用与POUs池中的不同库管理器，占位解析因而具有多处来源。原页提醒，解析结果只有在编译过程中可见，不能仅凭管理器中的占位信息，事前可靠地读出最终结果。这里说的是文档所列的可见性，不是本文对某个项目做过编译。

来源之间还存在明确的查找次序。应用库管理器的当前占位定义位于前面，随后是所用设备的描述、已安装附加组件，最后是POUs视图库管理器的占位表。这不是几份可以随意合并的同义清单：同一占位标识在解析时，需要放回这些来源与应用上下文中理解。本文说明这项层级，不列界面操作或修改项目的步骤。

结果在库管理器中以Effective version呈现。如果各个解析环节都没有成功，该库会标为not resolved，并且不被纳入编译。这个后果让“库条目仍然存在”与“已有可供应用使用的实际库”形成区别。单看列表里有名称，无法替这两种状态作出相同描述；反过来，未解析也不是文档为所有运行时问题给出的统一诊断。

版本条件另有具体界线。从编译器3.5.18.0起，原页说library profile不再参与占位解析，占位变为free placeholders。这里的变化限定在该编译器版本与解析规则，不能由free一词推断库没有版本或没有来源。Info栏仍列出设备描述、许可机制、附加组件以及固定版本特殊库等解析类别，帮助说明一项结果由什么关系形成。

NotImplementedByDevice又保留一种特定情形。文档说，有些占位本应由运行时实现的库填充，但当前运行时不支持这些库，于是CODESYS使用这一名称参与解析。名称出现在项目说明里，不能被转述成功能已经由设备实现。本文保留这种对象关系，没有采用后续条件编译、补充实现或错误处理的做法。

因此，一份完整的库资料说明可以连贯地写清占位叫什么、当前项目解析到什么、结果在具体应用的编译中怎样呈现，并带上相应版本条件。它比只核一列库名称更接近原文实际讨论的问题。该页首发日未知；本文未安装、更新或编译任何库，也不为生产项目作兼容与控制安全判断。