后台管理界面这东西做久了你会发现一个规律需求方永远只关心能不能快点上线、好不好用、界面别太丑而真正写代码的人要操心的是表格分页、表单校验、弹层通信、tab 切换这些琐碎但又绕不开的活。LayuiAdmin 这套基于 Layui 的后台界面方案就是冲着这个矛盾来的——它把后台里最常出现的那些 UI 界面元素比如侧边菜单、数据表格、弹层、tab 页签提前拼装成一套可以拿来就用的骨架。我第一次接触它是在一个内部运营系统的项目里需求给的工期只有两周前后端加起来两个人要是从零写一套布局光是对齐菜单和面包屑就得磨掉好几天。用了 LayuiAdmin 之后基本上第一天就把主框架跑起来了后面全部时间都花在业务逻辑上。这篇东西不打算给你讲什么高深理论就是把我在实际项目里用 LayuiAdmin 搭 UI 界面的完整过程、踩过的坑、以及一些能让界面跑得更顺的小技巧尽量说透适合刚接手后台项目的新手也适合用惯了重型前端框架、想换个轻量方案的老手参考。1. 为什么后台系统还值得用 LayuiAdmin 这样的方案1.1 从 Layui 的定位说起它到底适合谁Layui 这个库的定位一直很明确它不追求成为那种全家桶式的工程化框架也不强制你上构建工具、写 JSX、搞状态管理。它就是一套拿来就能用的 UI 组件集合核心是原生 HTML、CSS、JavaScript 三件套外加一个自己的模块加载器。你打开一个页面引入一个 layui.css 和一个 layui.js剩下的表格、表单、弹层、日期选择器就都能直接调用了。这一点对很多中小型后台项目来说相当关键因为这类项目的生命周期往往不长团队规模也小上重型框架带来的构建配置、依赖管理、学习成本最后很可能得不偿失。LayuiAdmin 则是建立在 Layui 之上的后台界面模板。它做的事情不是加新组件而是把 Layui 的组件按照后台管理的典型布局重新组织了一遍左边是折叠菜单顶部是用户信息和面包屑中间是内容区内容区里用 iframe 或者 tab 页签承载不同的功能页面。这套布局看起来简单但真正自己从零写的时候菜单折叠的动画、tab 的切换与缓存、iframe 的高度自适应每一项都是坑。LayuiAdmin 把这些坑提前填好了你拿到的是一份可以运行的完整骨架改改菜单配置、换换配色就能变成自己的后台。我在选型的时候对比过几类方案。重型框架功能强大但对小团队来说光是搭脚手架、配路由、搞权限前期投入就很大纯手写的话灵活性最高但重复劳动太多每个项目都要重新实现一遍同样的表格和弹层。LayuiAdmin 处在一个比较舒服的中间位置上手快、结构清晰、文档里的示例基本能直接抄同时又不至于像某些低代码平台那样失去控制权。所以我的结论是如果你的项目是内部管理系统、运营后台、数据看板这类页面对交互的复杂程度要求不算极致团队又没有专职前端那 LayuiAdmin 这类方案非常值得考虑。1.2 LayuiAdmin 到底解决了哪些具体麻烦很多人第一次听到后台模板会觉得这不就是几个静态页面吗能省多少事。实际用下来它省掉的恰恰是最容易让人烦躁的那部分。第一个麻烦是整体布局的响应式处理。后台界面在不同分辨率下侧边菜单要能收起内容区要能自适应宽度顶部栏要固定这些用纯 CSS 写要反复调试。LayuiAdmin 的布局基于 Layui 的栅格和 flex 体系收放逻辑已经写好你只要保证内容区的东西不超出容器宽度就行。第二个麻烦是 tab 页签的管理。后台系统通常同时打开好几个功能页用户希望切回来的时候之前的状态还在。用 iframe 承载的话天然就有状态保留的效果但随之而来的是 tab 的增删、激活、刷新、关闭这些操作需要一套统一的管理逻辑。LayuiAdmin 里的 tab 管理封装得比较完整新增页签、切换到指定页签、关闭当前页签这些都有现成的接口你只要在菜单点击事件里调一下就行。第三个麻烦是权限和菜单的对应关系。后台系统的菜单通常要根据用户角色动态生成LayuiAdmin 的菜单是数据驱动的你从后端返回一份菜单 JSON前端遍历渲染配合后端的接口鉴权一套基本的权限控制就成型了。这些加在一起省下的绝对不是一两天而是实打实的一到两周。2. 上手前必须搞清的目录结构与核心机制2.1 目录结构逐个拆解别急着改代码拿到 LayuiAdmin 之后第一件事不是打开编辑器就改而是把目录结构看懂。典型的目录大致分成这么几块layui目录放的是 Layui 的核心库包括 css、字体图标、以及各个组件的 js 模块这个目录原则上一动都别动升级的时候直接整体替换config.js或者layui.config那一段是模块路径配置它告诉 Layui 各个自定义模块去哪找这个文件非常关键后面加自己的模块都要在这里登记views或者pages目录放的是各个功能页面每个页面通常是一个独立的 HTML被 iframe 加载或者被 tab 动态创建modules目录放你自己写的扩展模块比如封装好的请求工具、通用表格方法。我见过不少人上来就把 layui 目录挪位置结果模块加载全乱套。原因是 Layui 的模块加载依赖它内部的 base 路径默认是按 layui.js 所在位置去推断的。你要是挪了目录就得在layui.config({ base: ... })里把新路径补上否则 layui.use 加载模块时会报 404。这个报错在控制台里的表现是某个模块 undefined或者直接提示找不到模块文件新手很容易误以为是自己代码写错了其实是路径问题。所以我的建议是前期尽量保持官方目录结构等整套项目跑通、业务开发告一段落再考虑要不要做目录美化。还有一个细节是入口文件。LayuiAdmin 通常有一个index.html或者home.html作为整个后台的壳菜单、顶部栏、tab 容器都在这个壳里。所有功能页面都是被这个壳加载进来的所以你在功能页面里想调用壳里的方法比如新增一个 tab、刷新当前页签就必须通过parent或者top去访问这一点后面讲 tab 通信的时候会展开。2.2 layui.use 的模块加载逻辑理解它就不怕报错Layui 用的是自己的模块加载机制核心方法就是layui.use。你写layui.use([table, form], function(){ ... })它会在回调触发前确保 table 和 form 这两个模块已经被加载。它的好处是按需加载页面里只用到表格就不必加载日期组件。但它的坑也很典型回调是异步的也就是说layui.use里面声明的变量外面直接访问会拿不到。我踩过一次很典型的坑。当时我在回调外面定义了一个函数想让它去操作表格对象结果发现表格对象是 undefined。后来才明白layui.use的回调执行时机是在模块加载完成之后而我在外面写的代码可能比它先执行。正确做法是把需要用到的逻辑全部放进回调里或者用一个全局变量把模块对象暴露出去等回调执行时再赋值。这个逻辑用一句话概括就是所有依赖 Layui 组件的代码都要写在layui.use的回调内部。另外要注意模块名和组件名的对应关系。表格模块是table表单是form弹层是layer日期是layui.laydate分页是layui.laypage。有些组件是独立模块有些则是挂载在 layui 主对象上的。写错名字的表现是回调里拿到的对象没有预期的方法比如调layer.open报 undefined那多半是模块名写错或者根本没引入layer。我的习惯是在每个功能页面的开头把这一页要用到的模块一次性声明清楚后面就不用反复纠结。2.3 菜单数据驱动的权限思路后台系统的菜单基本都是从后端来的前端写死的菜单只能用于演示。LayuiAdmin 的菜单渲染思路是遍历一份数组根据每项的url、icon、title、children去生成对应的 HTML。这份数组从哪来就决定了权限体系怎么设计。常见做法是后端根据当前登录用户的角色查角色-菜单关联表返回该用户可见的菜单树。这里有个经验点值得说菜单树和接口权限是两回事别以为前端藏了菜单就安全了。用户完全可能手动拼 URL 去访问某个他看不到的页面。所以菜单控制只是体验层面的优化真正的安全要靠后端在每个接口上做鉴权。我在项目里通常会让后端返回的菜单项里带一个权限标识前端在渲染按钮、控制操作项显隐时读这个标识但最终的写操作接口一律在后端再校验一遍当前用户有没有这个权限。这样即使有人绕过前端后端也能挡住。菜单树的结构建议不要嵌套太深三级以上用户就点得很累了。如果一个业务模块下面的功能特别多可以拆成多个一级菜单或者放进 tab 里用页签切换而不是继续往下套层级。3. 从零搭一个可用的管理页面3.1 环境准备与静态资源引入这一块看起来最简单但恰恰是新手翻车最多的地方。你不需要装 Node、不需要 npm只需要一个能跑静态文件的环境。很多人第一步就卡在没有 npm 怎么开发其实 Layui 的时代就是直接用浏览器打开的你只要把整个项目目录拖进编辑器配一个本地静态服务器就行。用 Python 的话一行命令就够python -m http.server 8080然后在浏览器里访问localhost:8080就能看到后台界面了。如果你用 FastAPI 做后端可以直接把 LayuiAdmin 的静态文件挂到应用里from fastapi import FastAPI from fastapi.staticfiles import StaticFiles app FastAPI() app.mount(/admin, StaticFiles(directorystatic/layuiadmin, htmlTrue), nameadmin)这样访问localhost:8000/admin就能打开后台同时你的接口也在同一个域名下省掉了跨域的麻烦。这里有个要点静态目录的htmlTrue参数很重要它会让访问目录时自动返回该目录下的 index.html否则你会看到 404。资源引入顺序上先引入 layui.css再引入 layui.js自定义的 css 和 js 放在最后这样你的样式能覆盖掉默认样式你的代码也能在 Layui 初始化之后执行。3.2 数据表格的完整实现从接口到渲染数据表格是后台系统里出场率最高的组件也是最能体现 LayuiAdmin 价值的地方。一个完整的表格至少包含这几件事列定义、数据请求、分页、搜索、行操作。先用table.render把表格渲染出来layui.use([table, form], function () { var table layui.table; table.render({ elem: #userTable, url: /api/users, method: get, page: true, limit: 20, limits: [10, 20, 50, 100], cols: [[ { type: checkbox, fixed: left }, { field: id, title: ID, width: 80, sort: true }, { field: username, title: 用户名, minWidth: 120 }, { field: status, title: 状态, width: 100, templet: #statusTpl }, { fixed: right, title: 操作, width: 160, toolbar: #rowBar } ]], parseData: function (res) { return { code: res.code, msg: res.msg, count: res.total, data: res.items }; } }); });这段代码里有几个关键点值得展开。parseData是格式转换的入口后端返回的字段结构未必和 Layui 期望的一致Layui 期望的是code、msg、count、data四个字段其中count是总条数data是当前页的数据数组。如果你的后端返回的是{total: 100, rows: [...]}就在这里转换。之所以要这么做是因为表格的分页控件需要知道总条数才能算出页数如果count没传对分页永远只有一页。templet用来自定义某一列的渲染比如状态列想显示成带颜色的标签就可以写一个模板。模板可以写在页面里的script typetext/html标签里用 id 引用。toolbar则是行操作列通常放编辑、删除按钮。行操作的点击事件用table.on(tool(userTable), function(obj){ ... })监听obj.data是当前行的数据obj.event是按钮的 lay-event 值根据这个值区分是编辑还是删除。表格重载是另一个高频操作搜索条件变化后需要按新条件重新拉数据table.reload(userTable, { where: { keyword: keyword, status: status }, page: { curr: 1 } });注意page: { curr: 1 }搜索之后要回到第一页否则如果当前在第 5 页搜索出来的结果只有 2 条你会看到一个空表格用户会以为没数据。这个细节看起来小但体验差别很大。3.3 弹层与表单联动把新增编辑做顺新增和编辑功能通常用弹层承载表单。Layui 的layer.open可以打开一个页面层内容直接写一段 HTML也可以指向一个独立页面。我的习惯是内容简单就写在页面里字段多就单独建一个 HTML 页面用 iframe 加载这样表单的校验逻辑和提交逻辑可以独立维护。function openUserForm(row) { var title row ? 编辑用户 : 新增用户; layer.open({ type: 2, title: title, area: [600px, 480px], content: user_form.html?id (row ? row.id : ), btn: [保存, 取消], yes: function (index, layero) { var iframeWin window[layero.find(iframe)[0][name]]; iframeWin.submitForm(); } }); }这里的关键是yes回调里怎么调用 iframe 内部的提交方法。layero.find(iframe)[0][name]拿到的是 iframe 的 name 属性Layui 会给它自动生成一个名字通过这个名字就能拿到 iframe 的 window 对象进而调用它里面的函数。这个写法我第一次见到的时候觉得很绕但用熟了就知道它是弹层和表单通信的标准姿势。表单页面里定义好submitForm函数在里面做校验和提交提交成功后调用parent.layer.close(index)关掉弹层并通知父页面刷新表格。行操作的删除按钮通常要加二次确认用layer.confirm弹一个确认框用户点确定后再发删除请求。删除成功后重载表格这里建议用table.reload而不是刷新整个页面因为刷新页面会把用户当前的搜索条件、分页状态全部丢掉体验很差。这一点和后面讲的 tab 刷新是同一个道理能局部更新的就不要整页刷新。4. layui tabs 刷新页面与 iframe 通信4.1 tab 机制原理解析为什么刷新这么麻烦LayuiAdmin 的 tab 页签本质上是一个标签容器每打开一个功能页就往容器里加一个标签同时创建一个 iframe 来承载页面内容。切换 tab 的时候其实是在切换 iframe 的显示隐藏而不是真的销毁重建。这个设计的好处是状态保留你在某个页面填了一半的表单切到别的 tab 再切回来内容还在。坏处是当你需要刷新这个页面的时候就得区分你到底想刷新什么。很多人遇到的问题是点了刷新按钮结果整个后台都重新加载了回到初始状态。原因是他用了location.reload()这个刷新的是当前整个窗口连外层壳一起刷了。正确做法是只刷新 iframe 内部也就是找到当前 iframe 的 window 对象调用它内部的 location.reload。在壳页面里可以这样写function refreshCurrentTab() { var iframe $(.layui-tab-item.layui-show iframe); if (iframe.length 0) { iframe[0].contentWindow.location.reload(); } }如果是在 iframe 内部想刷新自己也行但更常见的需求是刷新别人。比如在详情页保存成功后想让列表页刷新一下数据。这时候不能刷新整个列表页那会重置分页更好的做法是调用列表页暴露出来的重载方法也就是前面说的table.reload。4.2 几种刷新方式的适用场景对比刷新这件事没有一招通吃得看场景选方法。我整理了一张对照表是我在实际项目里反复验证过的刷新方式实现要点适用场景副作用iframe 内部 reloadiframe.contentWindow.location.reload()当前页数据来源多不好局部更新会重置页面内所有状态表格重载跨 iframe 调用table.reload只是列表数据变了分页会回到指定页表单重置调用 iframe 内的 resetForm 方法新增页重新填写需页面内配合整窗刷新location.reload()极少数需要重载所有资源的场景所有 tab 全部关闭从表里能看出来整窗刷新是优先级最低的选择除非真的出现资源加载错乱这种玄学问题否则别用。我一般要求团队里的人在写保存后刷新这类逻辑时优先考虑调用目标的局部刷新方法把刷新的粒度尽量做小这样用户的操作上下文不会被破坏。跨 iframe 调用的写法有几个变体需要记住。在父页面调用子页面document.getElementById(iframeId).contentWindow.someFunc()。在子页面调用父页面parent.someFunc()或者window.parent.someFunc()。最顶层用top。这几个关系理清楚了tab 之间的通信就不难了。4.3 动态新增与关闭 tab 的实用写法除了刷新新增和关闭 tab 也是很常用的操作。新增 tab 通常有两种触发方式点菜单自动新增或者在页面里通过按钮跳转。点菜单的那套逻辑 LayuiAdmin 已经封装好了你只要保证菜单项里的 url 指向正确的页面就行。页面内主动新增 tab 的场景更多见于查看详情这类操作比如列表页点某一行希望在旁边开一个新 tab 展示详情而不是跳走。function openTab(url, title) { var tab parent.layui.element.tab; // 先检查是否已存在同名 tab存在则切换不存在则新增 parent.layui.element.tabAdd(admin-tab, { title: title, content: iframe src url frameborder0/iframe, id: tab- Date.now() }); }这里有个经验新增之前最好先判断一下是否已经有相同 url 的 tab 打开了如果有就直接切过去而不是再开一个。否则用户反复点同一个详情会开出一堆重复标签体验很乱。判断的方法可以给每个 tab 的 id 用一个和业务相关的稳定标识比如tab-user-detail-123新增前先查这个 id 存不存在。关闭 tab 的时候要注意如果关闭的是当前激活的 tab最好自动激活前一个而不是让内容区空着。这些细节 LayuiAdmin 的 tab 组件部分帮你处理了但具体行为还是建议实际点一遍确认因为不同版本的表现可能略有差异。5. UI 界面卡顿的排查与优化5.1 先把卡顿的来源定位清楚界面卡顿是个很泛的描述得先拆开看是什么卡。是打开页面时加载慢还是操作时响应慢还是滚动的时候掉帧。加载慢通常是资源体积或接口响应的问题操作响应慢多半是 DOM 操作太频繁或者一次渲染的数据太多滚动掉帧则可能是因为页面里有大量的悬浮元素或者复杂的 CSS 阴影。定位的时候打开浏览器的性能面板录一段就能大致看出瓶颈在 JS 执行、渲染还是网络。我遇到最多的情况是表格数据量大导致的卡顿。一页展示 500 条数据每行又有很多列浏览器要生成几千个 DOM 节点还要给每个节点绑定事件渲染时间就会很长。解决方案不是优化渲染算法而是从源头控制数量分页限制每页最多 50 到 100 条超过这个量就该考虑虚拟滚动或者用搜索条件缩小范围。后台系统的用户其实很少会去翻第 30 页与其让他翻页不如让他用搜索精确找。5.2 表格渲染与事件绑定的优化手段Layui 的表格在渲染大量数据时确实会吃力但有些技巧可以显著改善。第一个是关闭不必要的自动渲染功能比如autoSort、cellMinWidth这些如果不需要就关掉能减少一些计算。第二个是列的宽度尽量写固定值用width而不是让表格自动计算自动列宽在数据多的时候计算开销不小。第三个是避免在templet里做复杂运算模板函数每行都会执行一次里面如果有循环或者复杂的字符串拼接500 行就是 500 次能省则省。事件绑定方面Layui 的表格用的事件委托模式本身是高效的但如果你在行里放了自定义的按钮并给每个按钮单独绑 click那就退化了。正确做法是用表格自带的tool事件通过lay-event属性区分操作这样只在外层绑一次事件。这个习惯我建议从一开始就养成别等到卡了再回头改。还有一点容易被忽略弹层关闭后如果没有正确销毁会残留 DOM 和事件监听开得多了内存占用会持续上涨。Layui 的 layer 在关闭时一般会清理但如果你的弹层里又嵌了别的组件要留意它们有没有各自的销毁逻辑。我一般会在弹层的end回调里手动做一些清理确保没有游离的定时器和监听器。5.3 网络请求层面能做的几件事前端卡顿有时候锅在接口。一个接口返回几 MB 的 JSON浏览器光解析就要几百毫秒渲染再花几百毫秒用户就感觉卡。解决办法是让接口只返回页面上真正需要的字段列表接口就别把详情字段全带回来。我见过一个列表接口返回了每个用户的完整头像 base64一页 20 条就是几 MB这纯属自己给自己找麻烦。另一个是接口合并。有些页面一打开就发好几个请求每个请求都要建立连接、等响应串起来就很慢。能把相关的数据合并成一个接口就合并。还有就是善用缓存一些不常变的数据比如字典、配置项可以在前端缓存起来不必每次都请求。这几点做下来页面打开速度的改善会非常明显。6. FastAPI 加 Layui 的前后端配合实践6.1 接口约定与统一返回结构后端和前端配合最重要的就是约定好数据的结构。后端返回什么形状前端parseData就按什么形状解析两边一旦说不清就会出现字段对不上、数据不显示的问题。我习惯约定一个统一的结构{ code: 0, msg: success, data: { }, total: 100 }用 FastAPI 的话可以封装一个统一的响应函数所有接口都走它保证格式一致。这样做的好处是前端写一套解析逻辑就能适配所有接口不用每个接口单独处理。错误处理也一样业务异常也返回这个结构只是code非零前端统一弹提示。from fastapi import FastAPI, Query from pydantic import BaseModel app FastAPI() class UserOut(BaseModel): id: int username: str status: int app.get(/api/users) def list_users(page: int 1, limit: int 20, keyword: str ): items, total query_users(page, limit, keyword) return {code: 0, msg: success, data: items, total: total}这里注意 Layui 的表格默认发的分页参数是page和limit你在 FastAPI 的接口里直接接这两个名字就行不用改前端。如果后端的分页参数习惯用pageNum、pageSize那就在table.render的request配置里改名两边对齐即可。6.2 分页、搜索、排序三件套的对接分页前面说过了重点在于total要传对。搜索则是把搜索框的值通过where传给后端后端在查询里加 where 条件。这里有个安全提醒搜索关键词拼接到查询里一定要注意参数化用 ORM 的 filter 或者参数化 SQL别直接字符串拼接否则会有注入风险。排序稍微复杂一点。Layui 表格点列头排序时会带上field和order两个参数需要后端根据字段名映射到实际的数据库列再拼排序条件。字段名映射这一步不能省因为前端传过来的字段名不能直接当数据库列名用一是安全二是可能名称不一致。我通常会维护一个白名单字典只允许有限的几个字段参与排序。SORT_FIELDS {id: id, username: username, status: status} app.get(/api/users) def list_users(page: int 1, limit: int 20, field: str , order: str ): sort_col SORT_FIELDS.get(field) query build_query() if sort_col: direction desc if order desc else asc query query.order_by(getattr(User, sort_col).desc() if direction desc else getattr(User, sort_col).asc()) return paginate(query, page, limit)白名单的思路很简单但很实用能挡掉绝大多数字段层面的风险。6.3 登录态与跨域的处理细节前后端分离或者半分离的项目登录态是个绕不开的话题。LayuiAdmin 这类静态页面的后台常见做法是登录接口返回一个 token前端存在 localStorage 或者 cookie 里之后每个请求带上。如果前端在同一个域名下用 cookie 最省事后端设置 httpOnly前端不用管。如果前端是独立部署的不同域名就要处理跨域后端要配 CORS允许携带凭证。用 FastAPI 配 CORS 很简单加上中间件就行。要特别注意allow_credentialsTrue的时候allow_origins不能配成*得写具体的域名否则浏览器会拒绝。这个坑我见过不少人踩表现是登录接口能通但带 cookie 的请求被浏览器拦掉控制台报 CORS 错误看半天以为是后端问题其实是配置冲突。from fastapi.middleware.cors import CORSMiddleware app.add_middleware( CORSMiddleware, allow_origins[http://localhost:8080], allow_credentialsTrue, allow_methods[*], allow_headers[*], )登录态失效的处理也要提前设计。token 过期后后端返回一个特定的 code前端拦截到之后统一跳转到登录页而不是让用户在一个接口一个接口地报错。这个拦截逻辑放在统一的请求封装里最合适所有接口走同一个请求函数出错了集中处理。7. 常见问题与排查速查7.1 问题速查表后台开发过程中有些问题反复出现我整理成了一张速查表遇到的时候对着查能省不少时间。现象可能原因处理办法表格数据不显示parseData 字段没对上打印接口返回值核对字段分页只有一页total 没传或传成当前页条数确认 total 是总记录数弹层里拿不到父页方法用了 window 而非 parent改成 parent.方法名刷新整个后台回到首页用了 location.reload改成 iframe 内部 reload模块 undefined模块名写错或未引入检查 layui.use 里的模块名表格越来越卡单页数据量过大限制 limit缩小搜索范围登录后请求 401凭证没带上或过期检查 token 注入和 CORS 配置菜单点击无反应菜单 url 路径错误核对静态资源路径和路由表格里的每一条都是我自己或者团队里踩过的尤其是弹层调父页方法那条新手基本都会遇到。写的时候记住一个口诀在 iframe 里想访问外层永远用parent或者top别无脑window。7.2 几个我反复强调的实操心得第一所有接口请求都走统一封装别在每个页面里各写各的 ajax。统一封装之后请求头注入、错误提示、登录态失效处理都只写一次后面新增页面直接复用。我见过一个项目十几个页面各自写请求后来要加一个 token 刷新逻辑改得痛不欲生。第二页面里的公共组件比如状态标签、操作按钮组尽量用模板抽出来别每个页面复制粘贴。复制多了之后样式一改就要改十几个地方早晚会漏。Layui 的模板引擎足够支撑这种程度的复用用起来也不复杂。第三开发阶段把控制台的报错当回事。Layui 有些问题是静默失败的比如模板 id 写错了表格那一列就空着不报错但你能通过检查 DOM 看出来。养成打开控制台看报错的习惯能提前发现很多问题。第四tab 用得越多越要注意内存。理论上开几十个 tab 不关浏览器内存会持续增长。虽然一般用户不会开那么多但如果你的后台功能特别多可以在关闭 tab 的时候顺手做一些清理或者限制同时打开的 tab 数量超出时关闭最久未使用的那个。最后分享一个我觉得挺实用的小技巧如果你想让某个操作在成功后不打断用户就别用整页刷新也别用弹窗提示成功而是在页面右上角做一个小范围的轻提示几秒后自动消失。这种反馈方式对用户的操作干扰最小后台系统用得越久越能体会到这种细节的价值。LayuiAdmin 加上 Layui 这套组合本质上就是帮你把这类细节提前想好了一大半剩下的就看你在实际项目里怎么把业务逻辑填进去。