WordPress插件和主题的版本号需手动写在特定注释头中：插件主文件开头用Version: x.x.x，主题的style.css同理；字段名大小写敏感，值须为纯字符串；更新提示依赖官方库或自定义API返回的元数据，PHP版本不被WordPress校验但影响兼容性。
WordPress 插件主题的版本号写在哪？
插件和主题的版本号不是由 PHP 自动管理的，而是靠你手动写在特定注释头里。WordPress 在加载时会解析这些注释，get_plugin_data() 和 wp_get_theme() 都依赖它。
插件主文件开头必须有类似这样的注释块：
/* Plugin Name: My Plugin Version: 2.1.0 */
主题的 style.css 也一样：
/* Theme Name: My Theme Version: 1.4.2 */
- 版本字段名固定是
Version（大小写敏感），不能写成version或VERSION - 值必须是纯字符串，不能是变量或函数调用，比如
Version: <?php echo MY_PLUGIN_VER; ?>无效 - 如果用了子主题，父主题的版本不会自动继承；子主题需单独声明自己的
Version
怎么让 WordPress 检测到新版本并提示更新？
光改本地 Version 没用。WordPress 更新检查器只认官方插件库（.org）或你配置的自定义更新源返回的元数据。
立即学习“PHP免费学习笔记（深入）”；
如果你发布在 wordpress.org：
- 每次提交新版本到 SVN，必须更新
readme.txt里的Stable tag，且该 tag 对应的目录下要有匹配的Version注释 -
Stable tag: 3.0.1→ 就得确保tags/3.0.1/my-plugin.php里写着Version: 3.0.1
如果是私有插件/主题，得自己实现更新 API，核心是让 wp_update_plugins() 能拿到含 new_version、package 字段的 JSON 响应，并确保本地插件的 Version 小于返回值。
PHP 本身不参与版本控制，但会影响版本兼容性判断
WordPress 不校验 PHP 版本，但你的插件/主题可能依赖高版本语法（如箭头函数、match 表达式）或扩展（如 ext-gd）。用户升级后白屏或报错，往往不是版本号问题，而是运行环境不匹配。
- 在插件主文件开头加运行时检测：
if (version_compare(PHP_VERSION, '8.0', '<')) {
add_action('admin_notices', function() {
echo '<div class="error"><p>My Plugin requires PHP 8.0+.</p></div>';
});
return;
}- 在
readme.txt的Requires PHP行注明最低要求，WordPress.org 会在插件页显示兼容性标识 - Composer 项目可设
"php": "^8.0"，但这只影响composer install，不影响 WordPress 运行时
Git 标签和 WordPress 版本号要对齐吗？
没必要强制一致，但强烈建议对齐。否则协作或回溯时容易混乱。
- 发布 v2.3.0 版本 → Git 执行
git tag -a v2.3.0 -m "Release v2.3.0"，同时确保所有Version:注释也改成2.3.0 - 不要用
v2.3.0标签却在代码里写Version: 2.3—— WordPress 认的是后者，用户看到的更新提示也会错乱 - 自动化发布脚本里，可以用
sed或 PHP 脚本批量替换Version:行，避免手误
最常被忽略的一点：子目录结构变更（比如把插件从 /myplugin/ 改成 /myplugin-pro/）会导致 WordPress 认为这是全新插件，旧版本记录清空，更新链断裂。路径即身份，比版本号还关键。
