mui基于material design规范，强调阴影层级、受控组件、js主题系统与设计约束；bootstrap以移动优先栅格为核心，支持非受控表单、sass主题编译与开箱手势，侧重适配自由与构建轻量。
Material Design 规范 vs 移动优先栅格系统
MUI 的设计哲学根植于 Google 的 Material Design 规范，它把界面当“纸”和“墨水”来建模：有明确的阴影层级（elevation）、过渡动效（theme.transitions）、色彩系统（primary/secondary 调色板）和响应式断点逻辑。而 Bootstrap 的设计起点是“如何让网页在不同设备上都可读可用”，它的 container、row、col 本质是为解决跨屏布局不确定性而生的栅格契约。
这意味着：用 MUI 做后台系统时，你得先想清楚“这个按钮该不该有 disableElevation”，而用 Bootstrap 时，第一反应常是“这列要不要加 col-md-6”。前者约束强、一致性高；后者自由度大、适配成本低。
组件 API 是受控还是声明式？
MUI 组件几乎全部采用 React 受控模式，比如 TextField 必须显式绑定 value 和 onChange，不传 value 就会警告；Bootstrap（通过 react-bootstrap）则更宽松：FormControl 允许非受控用法（靠 ref.current.value 读取），也支持受控，但不强制。
- 常见错误现象：
Warning: A component is changing an uncontrolled input to be controlled—— 这在 MUI 中高频出现，根源常是初始value为undefined，后续变成字符串 - 使用场景：表单复杂、需细粒度校验/联动时，MUI 的受控契约反而减少隐式状态；快速搭原型或对接旧逻辑时，Bootstrap 的灵活性更省事
- 性能影响：MUI 每次输入都触发完整 re-render（尤其嵌套
FormControl+FormHelperText），Bootstrap 的轻量封装对简单输入更友好
主题定制是改 JS 对象还是覆盖 CSS 类？
MUI 主题是运行时 JS 对象（createTheme 返回值），所有样式最终由 Emotion 或 Styled Components 动态注入；Bootstrap 主题靠预编译 Sass 变量（$primary、$grid-breakpoints）+ CSS 重写，构建时即固化。
这就导致：MUI 支持深色模式切换、用户偏好实时响应（useTheme() + useMediaQuery），但生产包体积含 Emotion 运行时；Bootstrap 主题切换需两套 CSS 文件手动加载，但最终产物就是纯 CSS，无 JS 开销。
- 容易踩的坑：MUI 升级到 v6 后，
makeStyles废弃，若项目还混用withStyles和sx，主题变量可能被意外覆盖 - 参数差异：
palette.mode: 'dark'在 MUI 中影响所有组件默认色，而 Bootstrap 的data-bs-theme="dark"只作用于内置 dark 模式组件，自定义组件得自己写 media query
移动端手势支持不是“有没有”，而是“谁管”
MUI 官方组件（如 Drawer、SwipeableDrawer）默认不处理 touchstart/touchmove，需要开发者手动接入 @mui/material/useScrollTrigger 或第三方库（如 hammerjs）；Bootstrap 的 Offcanvas 和 Carousel 则开箱支持 swipe 手势，底层已封装 touch-action: pan-y 和事件节流。
这不是能力高低问题，而是分工逻辑不同：MUI 把交互逻辑交给业务层决策（比如是否允许 drawer 在内容区滑动），Bootstrap 把“移动端该有的体验”直接 baked in。
真正在微信内嵌 WebView 或 PWA 场景下做滑动手势，别只盯着框架文档——iOS Safari 的 touch-action 默认行为、Android Chrome 的 passive event listener 限制，才是卡顿和失效的真正源头。
