Bootstrap 与 WordPress 冲突主因是 jQuery 兼容模式、类名覆盖及加载顺序错乱;应通过 wp_enqueue_script 声明依赖、禁用后台加载、使用命名空间或按需编译 CSS,并用 Walker 类适配导航菜单。
jQuery 是兼容模式(noConflict),而 Bootstrap 4+ 的 JS 插件(如 dropdown、modal)依赖全局 $。不处理的话,控制台常报 TypeError: $(...).modal is not a function 或 Uncaught ReferenceError: $ is not defined。另外,WordPress 主题自带的样式(比如 .button、.screen-reader-text)和 Bootstrap 的同名类会互相覆盖。wp_enqueue_script 中声明 jquery 为依赖,并把 Bootstrap JS 放在 jQuery 之后加载 <script> 标签,否则绕过 WordPress 脚本依赖管理,容易错序 wp_add_inline_script 注入了 jQuery 扩展,Bootstrap 的 JS 可能被提前执行 bootstrap.bundle.min.js(含 Popper),或分别引入 @popperjs/core + bootstrap.min.js functions.php 中用 wp_enqueue_style 和 wp_enqueue_script 注册资源,不要硬编码 <link> new bootstrap.Modal(...)) wp_enqueue_style('bootstrap-css', get_template_directory_uri() . '/css/bootstrap.min.css');wp_enqueue_script('popper-js', get_template_directory_uri() . '/js/popper.min.js', [], '2.11.8', true);wp_enqueue_script('bootstrap-js', get_template_directory_uri() . '/js/bootstrap.bundle.min.js', ['popper-js'], '5.3.3', true);
.container、.row、.text-center 这类通用类会被编辑器 UI 组件意外匹配。is_admin() 时跳过 wp_enqueue_style) <div class="my-theme-bootstrap"> 包住内容,再重写部分选择器:.my-theme-bootstrap .btn { ... } block.json 控制,Bootstrap 的 .d-none、.p-3 等工具类不会自动作用于块内,别指望它们“开箱即用”wp_nav_menu() 输出的是纯 <ul><li> 结构,而 Bootstrap navbar 需要特定 class(如 navbar-nav、nav-item、nav-link)和嵌套逻辑(如下拉菜单的 dropdown-menu)。wp_nav_menu() 的 'walker' 参数,传入自定义 Walker 类,重写 start_el() 和 start_lvl() 方法来注入 Bootstrap class 'items_wrap' 参数包裹默认输出,并配合 CSS 选择器补全行为(但下拉交互仍需 JS 初始化) <a> 有 data-bs-toggle="dropdown",且 <ul class="dropdown-menu"> 是紧邻的下一个兄弟元素 —— 默认 WordPress 输出不满足,必须靠 Walker 或 JS 修补 items_wrap):wp_nav_menu(['theme_location' => 'primary','items_wrap' => '<ul id="%1$s" class="navbar-nav me-auto %2$s">%3$s</ul>',]);这只能解决结构,下拉仍需额外 JS 或 Walker 补全属性
Bootstrap 和 WordPress 并非天然一对,真正麻烦的不是“怎么加”,而是“加完后哪些地方悄悄坏了”——比如搜索框变宽、评论表单错位、移动端汉堡菜单点不动。这些往往出现在子主题更新、插件启用或 Gutenberg 升级之后,得留心检查 DOM 结构和控制台错误。