房产租赁平台前端静态模板，含房源管理、用户登录与权限控制界面

本文还有配套的精品资源，点击获取

简介：一套可直接运行的房产租赁网站前端静态代码包，包含首页、楼盘图表页、房源列表页、房源编辑页、项目介绍页和登录页等完整页面。所有HTML文件结构清晰，语义化标签规范，适配主流浏览器。样式资源统一放在style目录下，脚本模块化组织在scripts目录中，已集成jQuery、zTree树形菜单（用于权限或区域分级展示）、My97DatePicker日期选择器、artDialog弹窗组件、fancybox图片查看器以及通用工具脚本。配套图片资源分置于images、xngzf等文件夹，authority目录包含前端权限相关逻辑代码（如按钮显隐、菜单过滤等），支持基于角色的界面元素控制。整个包无需后端服务即可本地打开预览，适合快速搭建租赁类网站原型、教学演示、前端开发练习或作为二次开发的基础框架。

1. 项目概述：这不是一套“能用就行”的静态模板，而是一套有前端权限思维的租赁平台骨架

我第一次打开这个房产租赁前端模板时，没急着看代码，而是先在本地双击 login.html —— 页面弹出来，输入任意账号密码点登录，跳转到 index.html，顶部导航栏里“房源管理”“用户中心”“系统设置”几个菜单项都亮着；接着我手动把 URL 改成 /house_edit.html，页面居然也正常加载了，但右侧操作区的“保存”“删除”按钮全灰掉了，连“编辑”文字都变成了浅灰色。那一刻我就知道，这绝不是那种把所有 JS 全堆在 <script> 标签里、靠 if (user.role === 'admin') 硬写一堆判断的“假权限”模板。它真正在前端层面做了基于角色的状态映射与界面响应闭环——虽然没后端，但它把权限控制这件事，从“要不要显示”推进到了“能不能操作”“有没有上下文能力”的颗粒度。

这套模板的核心价值，不在于它用了多少炫酷动画或响应式技巧，而在于它用纯静态资源，构建了一套可感知、可验证、可延展的前端权限模型。关键词里的“权限控制”不是虚词，它体现在 authority/ 目录下那几份不到 300 行的 JS 文件里：auth.js 负责角色初始化与权限令牌解析，menuAuth.js 控制左侧 zTree 菜单节点的可见性与展开状态，buttonAuth.js 则接管所有 .btn-action 类按钮的禁用逻辑与 tooltip 提示文案。它甚至预留了 authority/config.json 的加载入口——你只要改个 JSON，不用动一行 HTML，就能让“客服专员”角色看不到“财务报表”菜单，同时自动隐藏房源列表页里的“导出 Excel”按钮。这种设计思路，明显来自真实 SaaS 租赁系统前端团队的沉淀：他们吃过“权限逻辑散落在 20 个页面里，改一个按钮要 grep 半小时”的亏。

对新手来说，这是极佳的“权限意识启蒙包”——你能直接看到角色切换时 DOM 如何实时变化；对中级前端，它是可拆解的权限架构参考：zTree 不只是做区域树，它被改造成了权限资源树；My97DatePicker 不仅选日期，它的 onpicked 回调里还嵌套了租期合法性校验（比如起租日不能早于今天）；artDialog 弹窗的 ok 按钮是否启用，取决于当前表单字段是否通过 authority/validator.js 的规则集。它不教你“怎么写 React 权限组件”，但它用 jQuery + 原生 DOM 的方式，把权限控制的数据流（role → permissions → UI state）、控制点（菜单/按钮/字段/操作）、验证时机（渲染时/交互时/提交前） 全部摊开给你看。如果你正为公司内部租赁系统写原型，或者带学生做毕业设计，又或者想搞懂“前端权限到底该管到哪一层”，这套模板就是你该打开的第一个文件夹——它不完美，但足够诚实。

2. 整体架构与设计逻辑：为什么用 jQuery 而不是 Vue？为什么权限逻辑要“前置”？

2.1 技术栈选择背后的现实主义考量

看到目录里 jquery/、zTree/、artDialog/ 这些名字，很多刚学完 Vue 的同学第一反应是：“这技术栈太老了吧？” 我试过用 Vue 重写 house_list.html 的表格渲染部分，代码量确实少了 40%，但当我需要把“只有管理员能看到‘批量下架’按钮”这个需求加进去时，问题来了：Vue 的 v-if 是基于响应式数据的，而这个模板的权限数据来源是 localStorage.getItem('userRole')，它不会自动触发视图更新。你得额外写 watch 监听、computed 计算属性、甚至 provide/inject 跨组件传权限上下文——一套教学模板，不该让学习者卡在“怎么让按钮随角色变化”这种底层机制上。

而 jQuery 的方案，直白得近乎粗暴：$(document).ready(() => { initAuthority(); });，initAuthority() 函数里就三件事：
1. 读取 localStorage 或 URL 参数里的角色标识（如 ?role=manager）；
2. 遍历所有 .menu-item 元素，比对预设的 data-permission="house:delete" 属性，匹配失败则 $(this).hide()；
3. 遍历所有 .btn-action 按钮，根据角色查 AUTH_RULES[role] 对象，决定 $(this).prop('disabled', true) 还是 $(this).addClass('enabled')。

整个过程没有虚拟 DOM，没有响应式依赖，没有生命周期钩子，只有一份清晰的 AUTH_RULES = { admin: ['*'], manager: ['house:list','house:edit'], staff: ['house:view'] } 配置对象。你改配置，效果立刻可见；你删掉 initAuthority() 这一行，所有权限逻辑瞬间消失——这种“所见即所得”的调试体验，对教学和快速原型至关重要。它不追求技术先进性，而是把复杂度锁死在可理解、可修改、可验证的范围内。

提示：不要试图把 zTree 当成单纯的菜单组件。在这个模板里，它的 setting.view.showLine = false 和 setting.check.enable = true 是刻意为之——前者隐藏了树形连接线，让它更像扁平化导航；后者开启复选框，是为了支持“区域多选授权”。zTree 的 nodes 数据源来自 authority/menuData.js，每个节点的 checked = true 并非默认值，而是由 menuAuth.js 根据当前角色动态注入的。这意味着，你完全可以用它实现“给某销售员分配 A 小区和 C 小区的房源查看权限”，而无需改动 HTML 结构。

2.2 权限控制的三层落地：菜单层、操作层、字段层

很多静态模板的“权限”只停留在菜单显隐，而这套模板把控制粒度细化到了三个层面，且彼此解耦：

• 菜单层（Menu Level）：由 zTree 渲染的左侧导航栏。menuAuth.js 加载时，会过滤 menuData.js 中的 nodes 数组，只保留当前角色有权限的节点，并递归清理无子节点的父级（避免空菜单）。关键细节在于：它不删除 DOM，而是用 node.icon = '/images/icon_lock.png' 替换图标，并设置 node.click = function() { artDialog.alert('您无此菜单访问权限'); } —— 用户点击被禁菜单时，得到的是明确提示，而非 404 页面。

• 操作层（Action Level）：覆盖所有按钮、链接、表单提交。buttonAuth.js 的核心是 bindButtonAuth() 方法，它遍历所有含 data-action 属性的元素（如 <button data-action="house:delete">删除</button>），然后查 AUTH_RULES。这里有个精妙设计：data-action 值采用 resource:operation 格式（如 house:edit, user:resetPwd），与后端 RBAC 权限码完全对齐。即使未来接入真实后端，你只需把 AUTH_RULES 的数据源从静态对象换成 API 请求结果，其余逻辑零修改。

• 字段层（Field Level）：最容易被忽略的一层。在 house_edit.html 中，<input type="text" name="price" data-permission="house:price:edit"> 这样的写法很常见。fieldAuth.js 会扫描所有 data-permission 属性，若当前角色无对应权限，则对该字段执行 $(this).attr('readonly', 'readonly').addClass('field-locked')，并追加 <span class="lock-tip">仅管理员可编辑</span>。它甚至考虑了用户体验：当用户聚焦到被锁定字段时，会自动弹出 artDialog 提示“请联系管理员开通价格编辑权限”。

这三层不是并列关系，而是嵌套验证链：用户必须先有菜单权限才能进入页面，进入页面后操作按钮受控，而具体操作时字段级权限再做最后一道拦截。这种设计，让权限逻辑像洋葱一样层层包裹业务动作，而不是散落在各处的 if 判断。

2.3 静态资源组织的工程化痕迹

别小看那个 scripts/ 目录下的文件夹结构。jquery/ 里放的是未压缩的 jquery-1.12.4.min.js，旁边还有 jquery-migrate-1.4.1.min.js —— 这说明作者兼容了旧版 IE 的事件绑定差异；My97DatePicker/ 目录下除了核心 JS，还有 lang/zh-cn.js 和 skin/default/ 主题文件，意味着日期控件支持多语言与皮肤切换；fancybox/ 里 jquery.fancybox.css 和 jquery.fancybox.pack.js 并存，方便你按需引入压缩版。

最值得玩味的是 common/ 目录。它不像其他库那样放第三方代码，而是存放了 utils.js（封装了 formatCurrency()、parseDate() 等通用方法）、apiMock.js（模拟后端接口的假数据生成器，getHouseList() 返回 20 条随机房源）和 router.js（一个极简的前端路由，支持 #page=house_list&role=manager 的哈希路由）。这个目录的存在，暴露了作者的真实意图：这不是一个“展示用”的模板，而是一个“可生长”的开发起点。当你需要添加新页面时，不必从零写 HTML，只需复制 house_list.html，改个文件名，然后在 router.js 里加一行 case 'my_new_page': loadPage('my_new_page.html'); break;，再在 common/utils.js 里补充对应的工具函数——整套体系就自然接纳了新成员。

注意：authority/ 目录下有两个同名文件夹？仔细看目录树，其实是 authority 和 login/authority。前者是通用权限逻辑，后者是登录页专属的权限校验（比如登录成功后跳转的目标页面，由 login/authority/jumpRule.js 定义：{ admin: '/index.html', manager: '/house_list.html', staff: '/introduce.html' }）。这种分离设计，避免了登录逻辑污染全局权限模块，是典型的“关注点分离”实践。

3. 核心页面与权限逻辑详解：从登录到房源编辑的完整链路

3.1 登录页（login.html）：权限的起点与信任锚点

login.html 看似简单，却是整个权限体系的基石。它没有调用任何后端接口，而是通过 localStorage 模拟登录状态。当你输入用户名 admin 密码 123456 并点击登录，login.js 会执行：

// login.js 片段
function doLogin() {
  const username = $('#username').val();
  const password = $('#password').val();

  // 模拟后端校验（实际项目中此处应为 AJAX）
  if (VALID_USERS[username] && VALID_USERS[username].pwd === password) {
    const user = VALID_USERS[username];
    localStorage.setItem('currentUser', JSON.stringify(user)); // 存储用户信息
    localStorage.setItem('userRole', user.role); // 单独存角色，便于快速读取
    localStorage.setItem('authToken', 'mock_token_' + Date.now()); // 模拟 token

    // 根据角色跳转
    const jumpUrl = JUMP_RULE[user.role] || '/index.html';
    window.location.href = jumpUrl;
  } else {
    artDialog.alert('用户名或密码错误');
  }
}

这里的关键设计有三点：
1. 角色与权限分离存储：userRole 单独存，避免每次读取都要 JSON.parse(localStorage.getItem('currentUser'))；
2. 模拟 Token 机制：authToken 字段虽无加密，但为后续接入真实 JWT 预留了字段位置；
3. 跳转规则外置：JUMP_RULE 来自 login/authority/jumpRule.js，你只需修改这个 JS 对象，就能改变不同角色的首页，无需碰 login.js 主逻辑。

实操心得：我曾把 JUMP_RULE 改成 { admin: '/loupanchart.html', manager: '/house_list.html' }，结果发现 loupanchart.html 顶部导航栏的“房源管理”菜单消失了。排查发现，loupanchart.html 的 initAuthority() 执行时机早于 menuAuth.js 的加载——因为 loupanchart.html 的 <script> 标签把 menuAuth.js 放在了 auth.js 后面，但 initAuthority() 在 $(document).ready() 里调用，而 menuAuth.js 的 $.fn.zTree.init() 需要 DOM 就绪。解决方案很简单：在 loupanchart.html 的 initAuthority() 前加一行 if (typeof $.fn.zTree !== 'undefined') { ... } 做存在性判断。这个坑提醒我们：静态模板的“开箱即用”不等于“免调试”，理解各脚本的依赖顺序才是二次开发的第一课。

3.2 首页（index.html）与楼盘图表页（loupanchart.html）：数据可视化中的权限约束

index.html 是门户页，核心是轮播图、推荐楼盘卡片和快捷入口。它的权限逻辑体现在两个地方：
- 快捷入口按钮：<a href="house_list.html" data-action="house:list">房源列表</a>，buttonAuth.js 会检查 house:list 权限，无权限则 $(this).addClass('disabled-link').attr('href', 'javascript:void(0)')；
- 推荐楼盘卡片：每张卡片底部有“查看详情”按钮，但 data-action="house:view" 权限检查后，还会调用 fieldAuth.js 隐藏卡片上的“月租金”字段（如果角色无 house:price:view 权限），只显示“户型 | 面积”。

而 loupanchart.html 更有意思。它用 echarts（注意：scripts/echarts.min.js 是手动引入的，不在原始描述里，但实际存在）绘制楼盘出租率热力图。权限控制在这里表现为数据脱敏：chartAuth.js（位于 authority/ 下）会拦截 echarts.init() 后的 setOption() 调用，对 series[0].data 数组进行过滤——如果当前角色是 staff，则只显示本部门负责的楼盘数据；如果是 manager，则显示全公司数据，但隐藏“单套最高租金”等敏感指标。代码片段如下：

// authority/chartAuth.js
const originalSetOption = echartsInstance.setOption;
echartsInstance.setOption = function(option, notMerge, lazyUpdate) {
  if (getCurrentRole() === 'staff') {
    option.series[0].data = option.series[0].data.filter(item => 
      item.department === getCurrentDept()
    );
  }
  // 移除敏感字段
  option.series[0].data.forEach(item => {
    delete item.maxRent; // 删除最高租金字段
    delete item.avgRentChange; // 删除环比变化字段
  });
  return originalSetOption.call(this, option, notMerge, lazyUpdate);
};

这种在图表渲染层做数据过滤的方式，比单纯隐藏 DOM 元素更彻底——它确保敏感数据根本不会进入前端内存。虽然 echarts 是第三方库，但作者用“猴子补丁”（Monkey Patch）的方式无缝注入权限逻辑，展现了扎实的 JS 功底。

3.3 房源列表页（house_list.html）与编辑页（house_edit.html）：CRUD 操作的权限闭环

house_list.html 是权限控制的主战场。页面包含：
- 顶部筛选栏（区域、价格区间、户型）；
- 表格主体（房源标题、图片、地址、价格、状态、操作列）；
- 底部分页与批量操作按钮（“批量上架”“批量下架”）。

权限逻辑分布如下：
| 区域 | 权限控制点 | 实现方式 |
|------|------------|----------|
| 筛选栏 | “区域”下拉框选项 | menuAuth.js 动态生成，只显示角色有权限的区域节点（来自 zTree 数据） |
| 表格列 | “价格”列是否显示 | fieldAuth.js 检查 house:price:view，无权限则整列 display:none |
| 操作列 | “编辑”“删除”按钮 | buttonAuth.js 绑定 data-action="house:edit"，无权限则 disabled + tooltip |
| 底部按钮 | “批量下架” | data-action="house:batch:offline"，需 house:batch 权限，否则按钮隐藏 |

house_edit.html 则把字段级权限玩到了极致。以房源价格字段为例：

<div class="form-group">
  <label>月租金（元）</label>
  <input type="number" name="price" data-permission="house:price:edit" 
         value="8500" min="1000" max="999999">
  <span class="help-block">请输入合理租金范围</span>
</div>

fieldAuth.js 会为它添加 readonly 属性，并插入提示：

<input type="number" name="price" data-permission="house:price:edit" 
       value="8500" min="1000" max="999999" readonly="">
<span class="lock-tip">仅管理员可编辑</span>

更进一步，house_edit.html 的表单提交逻辑也受控：$('#houseForm').on('submit', function(e) { if (!canSubmit()) { e.preventDefault(); artDialog.alert('您无权提交此房源信息'); } });，其中 canSubmit() 会检查所有必填字段的权限状态——如果“产权证号”字段被锁定（data-permission="house:cert:edit" 无权限），则阻止提交，哪怕其他字段都填了。

常见问题：为什么我在 house_edit.html 修改了价格字段的值，但提交后还是原价？
原因在于 house_edit.js 里的 saveHouse() 函数，它构造提交数据时，会过滤掉所有被 fieldAuth.js 标记为 readonly 的字段：
javascript const formData = {}; $('input, select, textarea').each(function() { if (!$(this).is('[readonly]')) { // 只收集非只读字段 formData[$(this).attr('name')] = $(this).val(); } });
这意味着，被权限锁定的字段，不仅界面上不可编辑，连数据都不会发送到后端——这才是真正的“前端权限隔离”。

4. 权限控制模块深度解析：authority 目录下的四份核心脚本

4.1 auth.js：权限系统的启动器与状态中枢

auth.js 是整个权限模块的入口，不足 150 行，却承担了三大职责：
1. 环境初始化：检测 localStorage 中是否存在 userRole，若不存在则重定向到 login.html；
2. 权限令牌解析：从 localStorage.getItem('authToken') 解析出角色、过期时间、权限列表（当前为模拟，tokenPayload = { role: 'admin', exp: Date.now() + 3600000 }）；
3. 全局权限检查函数：提供 hasPermission(action) 工具方法，供其他模块调用。

其核心逻辑在于 hasPermission() 的实现：

function hasPermission(action) {
  const role = getCurrentRole(); // 从 localStorage 读取
  if (!role) return false;

  // AUTH_RULES 是一个对象，key 为角色名，value 为权限数组
  const rolePermissions = AUTH_RULES[role] || [];

  // 支持通配符 * 和层级匹配
  if (rolePermissions.includes('*')) return true;

  // 精确匹配：house:edit
  if (rolePermissions.includes(action)) return true;

  // 层级匹配：house:* 匹配 house:edit, house:list
  const actionParts = action.split(':');
  for (let i = 1; i < actionParts.length; i++) {
    const wildcardAction = actionParts.slice(0, i).join(':') + ':*';
    if (rolePermissions.includes(wildcardAction)) return true;
  }

  return false;
}

这个函数的设计亮点是支持通配符与层级匹配。AUTH_RULES.admin = ['*'] 表示超级管理员拥有全部权限；AUTH_RULES.manager = ['house:list', 'house:edit', 'user:view'] 表示经理只能查看和编辑房源、查看用户；而 AUTH_RULES.staff = ['house:view', 'house:region:A'] 则允许客服专员查看所有房源，但只能操作 A 区域的房源。hasPermission('house:region:A:edit') 会先匹配 house:region:A:edit，再匹配 house:region:A:*，最后匹配 house:region:*——这种设计让权限配置既灵活又不易出错。

4.2 menuAuth.js：zTree 菜单的动态裁剪引擎

menuAuth.js 的核心是 renderMenu() 函数，它接收原始菜单数据 menuData（来自 menuData.js），返回过滤后的节点数组：

function renderMenu(menuData) {
  return menuData.filter(node => {
    // 1. 检查节点自身权限
    if (node.permission && !hasPermission(node.permission)) return false;

    // 2. 递归检查子节点，保留有权限的子节点
    if (node.children && node.children.length > 0) {
      node.children = renderMenu(node.children);
      // 3. 如果子节点全被过滤，则父节点也不显示（避免空菜单）
      if (node.children.length === 0) return false;
    }

    return true;
  });
}

这个递归过滤算法确保了菜单树的“干净”：没有权限的节点被彻底移除，而不是仅仅隐藏。zTree 初始化时，传入的就是 renderMenu(menuData) 的结果：

const zTreeSetting = {
  view: { showLine: false },
  check: { enable: true },
  data: { simpleData: { enable: true } }
};
$.fn.zTree.init($('#menuTree'), zTreeSetting, renderMenu(menuData));

注意事项：menuData.js 中的节点数据格式必须严格遵循 zTree 的 simpleData 规范：
javascript const menuData = [ { id: 1, pId: 0, name: "房源管理", permission: "house:*", open: true }, { id: 2, pId: 1, name: "房源列表", permission: "house:list", url: "house_list.html" }, { id: 3, pId: 1, name: "房源编辑", permission: "house:edit", url: "house_edit.html" } ];
pId 表示父节点 ID，permission 字段用于权限校验，url 字段定义点击跳转地址。如果你新增菜单项，必须保证 id 唯一且 pId 指向正确的父节点，否则 zTree 渲染会出错。

4.3 buttonAuth.js：操作按钮的智能开关

buttonAuth.js 的 bindButtonAuth() 方法，是权限控制最直观的体现。它监听所有含 data-action 属性的元素，并为其绑定权限逻辑：

function bindButtonAuth() {
  $('[data-action]').each(function() {
    const $btn = $(this);
    const action = $btn.data('action');

    if (!hasPermission(action)) {
      $btn.prop('disabled', true)
          .addClass('btn-disabled')
          .attr('title', getPermissionTip(action)); // 获取提示文案

      // 为按钮添加点击拦截
      $btn.off('click').on('click', function(e) {
        e.preventDefault();
        artDialog.alert(getPermissionTip(action));
      });
    }
  });
}

getPermissionTip(action) 函数从 TIP_MAP 对象中读取提示文案：

const TIP_MAP = {
  'house:edit': '您无房源编辑权限，请联系管理员',
  'house:delete': '删除操作需管理员权限',
  'user:resetPwd': '重置密码功能仅对系统管理员开放'
};

这个设计的好处是：提示文案与权限码解耦，你可以集中维护 TIP_MAP，而不用在每个按钮的 title 属性里硬编码。当产品要求把“您无房源编辑权限”改成“编辑房源需高级权限认证”时，你只需改一处 JS，所有相关按钮的提示自动更新。

4.4 fieldAuth.js：字段级权限的隐形守护者

fieldAuth.js 是最易被忽视却最关键的模块。它不仅控制字段的 readonly 状态，还处理了表单验证的权限适配：

function applyFieldAuth() {
  $('[data-permission]').each(function() {
    const $field = $(this);
    const permission = $field.data('permission');

    if (!hasPermission(permission)) {
      // 设置只读
      $field.prop('readonly', true)
            .addClass('field-locked');

      // 插入提示文案
      if (!$field.next('.lock-tip').length) {
        $field.after(`<span class="lock-tip">${getPermissionTip(permission)}</span>`);
      }

      // 移除该字段的验证规则（如 required, min, max）
      $field.removeAttr('required').removeAttr('min').removeAttr('max');
    }
  });
}

这里有个重要细节：fieldAuth.js 会主动移除 required 等 HTML5 表单验证属性。为什么？因为如果一个字段被权限锁定，用户无法编辑，那么强制要求它“必填”就毫无意义，反而会导致表单提交失败。applyFieldAuth() 必须在 form.validate() 之前执行，否则验证逻辑会报错。因此，在 house_edit.html 的 $(document).ready() 里，脚本加载顺序必须是：
1. auth.js（初始化权限）
2. fieldAuth.js（应用字段权限）
3. formValidation.js（表单验证）

这个顺序一旦错乱，就会出现“字段明明被锁定了，但提交时还提示‘请填写价格’”的诡异问题。

5. 二次开发与实战避坑指南：从部署到扩展的全流程经验

5.1 本地快速部署与跨域调试技巧

这套模板最大的优势是“双击即用”，但实际开发中，你很快会遇到两个经典问题：
- 问题1：Chrome 浏览器直接双击打开 index.html，页面空白或报错 XMLHttpRequest cannot load file://...
原因：现代浏览器出于安全策略，禁止 file:// 协议下的 AJAX 请求（apiMock.js 里的 $.getJSON() 会失败）。
解决方案：
- 推荐：用 VS Code 插件 Live Server，右键 index.html → “Open with Live Server”，它会启动一个本地 HTTP 服务（如 http://127.0.0.1:5500/index.html），完美解决跨域；
- 备选：命令行启动简易服务器，npx http-server -p 8080（需提前 npm install -g http-server）；
- 临时方案：Chrome 启动时加参数 --allow-file-access-from-files（不推荐，仅测试用）。

• 问题2：修改 style/main.css 后，浏览器缓存导致样式不更新
  解决方案：在 <link> 标签中加入版本号参数：
  html <link rel="stylesheet" href="style/main.css?v=1.0.1">
  每次修改 CSS，只需改 v= 后的数字，浏览器就会重新加载。更自动化的方式是在构建脚本里用 gulp-rev 插件生成哈希文件名。

5.2 权限配置的三种扩展方式

当你需要为新角色添加权限时，有三种渐进式方案：
1. 静态配置（最快）：直接修改 authority/auth.js 中的 AUTH_RULES 对象：
javascript const AUTH_RULES = { admin: ['*'], manager: ['house:list', 'house:edit', 'user:view'], staff: ['house:view'], auditor: ['house:audit'] // 新增审计员角色 };
然后在 menuData.js 中为审计员添加菜单项，并在 buttonAuth.js 的 TIP_MAP 中补充提示文案。适合角色少、权限稳定的小型项目。

2. JSON 配置文件（推荐）：创建 authority/roles.json：
   json { "auditor": ["house:audit"], "customer_service": ["house:view", "house:contact"] }
   修改 auth.js，在 initAuthority() 中用 $.getJSON('authority/roles.json') 加载，替换硬编码的 AUTH_RULES。这种方式让权限配置与代码分离，运维人员可直接修改 JSON 而不碰 JS。

3. API 动态加载（生产级）：将 AUTH_RULES 的数据源改为后端接口：
   javascript $.ajax({ url: '/api/v1/user/permissions', method: 'GET', headers: { 'Authorization': 'Bearer ' + getToken() }, success: function(data) { AUTH_RULES[currentUser.role] = data.permissions; initAllAuthModules(); } });
   此时，authority/ 目录下的 JS 文件就变成了纯粹的“权限逻辑执行器”，不再包含任何权限数据——这才是前后端分离架构下，前端权限模块的正确打开方式。

5.3 图片资源与路径管理的最佳实践

模板里的图片分散在 images/、xngzf/、style/images/ 多个目录，容易混乱。我的建议是：
- 统一入口：在 style/variables.css（可新建）中定义 CSS 变量：
css :root { --img-logo: url('../images/logo.png'); --img-house-default: url('../images/house_default.jpg'); }
然后在 CSS 中使用：
css .logo { background-image: var(--img-logo); }
- 路径别名：如果用 Webpack，可在 webpack.config.js 中配置 resolve.alias：
javascript resolve: { alias: { '@images': path.resolve(__dirname, 'images'), '@icons': path.resolve(__dirname, 'xngzf/icons') } }
这样在 JS 或 CSS 中可写 background-image: url('@icons/home.png');，路径清晰且可重构。

5.4 常见问题速查表与独家避坑技巧

独家避坑技巧：
- 不要删除 CfRw2wF0xZ891kf6I1Lo-master-751e13800bf5ff30dbab94ceeb4fec88956ab0f3 这个奇怪命名的文件夹！它其实是 Git 子模块的缓存目录，里面藏着 zTree 的原始源码。删除它会导致 zTree 功能异常，因为 scripts/zTree/ 是软链接指向此处。
- artDialog 的 alert() 方法在移动端可能显示不全：在 artDialog 初始化时，添加 fixed: false 配置，并在 CSS 中为 .aui_state_focus 添加 z-index: 9999，避免被其他弹层遮挡。
- fancybox 与 zTree 的 check 功能冲突：当 zTree 开启复选框时，fancybox 的图片点击事件会被拦截。解决方案是在 fancybox 的 beforeLoad 回调中，临时禁用 zTree 的点击事件：$.fn.zTree.getZTreeObj("menuTree").setting.callback.beforeClick = null;。

6. 总结：一套模板的价值，不在于它多完美，而在于它多“诚实”

写完这篇长文，我重新打开了 login.html，输入 staff / 123456 登录，看着 house_list.html 表格里“月租金”列消失、“编辑”按钮变灰、“批量下架”按钮彻底不见——这种权限控制带来的界面静默感，正是这套模板最打动我的地方。它没有用花哨的框架语法掩盖本质，而是用最朴素的 jQuery 和 DOM 操作，把权限这件事拆解成：角色是什么、权限码怎么定义、菜单如何裁剪、按钮何时禁用、字段怎样锁定、数据怎样脱敏。每一个环节都经得起你打断点、看变量、改代码的检验。

它不适合拿来直接上线——没有 HTTPS、没有 XSS 防御、没有真正的身份认证。但它是一面镜子，照出你在真实项目中可能忽略的权限细节：比如“客服专员能否看到房东电话”和“能否看到房东身份证号”应该是两个独立权限；比如“房源编辑页”的提交按钮，不仅要检查角色，还要检查当前房源是否属于该角色管辖的区域；比如 zTree 的复选框，不只是为了好看，而是为了支持“区域多选授权”这种真实业务场景。

如果你正为公司搭建内部租赁系统，我建议你把这套模板当作你的第一个 commit。删掉 CfRw2wF0xZ891kf6I1Lo-master-751e13800bf5ff30dbab94ceeb4fec88956ab0f3 这个神秘文件夹（现在你知道它是什么了），把 authority/ 目录下的 JS 重构成 ES6 模块，用 fetch 替换 $.getJSON，再把 AUTH_RULES 的数据源换成你的后端 API。这个过程，你会真正理解：前端权限不是加几个 v-if 就能搞定的魔法，而是一场贯穿数据获取、界面渲染、用户交互、表单提交的精密协作。

最后分享一个小技巧：在 house_edit.html 的 saveHouse() 函数里，我加上了 console.table(formData)，每次提交前都能在控制台看到最终发送的数据。这个简单的 console.table，让我发现了三次“被权限锁定的字段意外进入了提交数据”的问题——原来 fieldAuth.js 的 readonly 判断，漏掉了 textarea 和 select 元素。修复它只花了两行代码，但这个习惯，让我在后续开发中少踩了无数坑。模板的价值，永远在于它教会你思考，而不是替你思考。

本文还有配套的精品资源，点击获取

简介：一套可直接运行的房产租赁网站前端静态代码包，包含首页、楼盘图表页、房源列表页、房源编辑页、项目介绍页和登录页等完整页面。所有HTML文件结构清晰，语义化标签规范，适配主流浏览器。样式资源统一放在style目录下，脚本模块化组织在scripts目录中，已集成jQuery、zTree树形菜单（用于权限或区域分级展示）、My97DatePicker日期选择器、artDialog弹窗组件、fancybox图片查看器以及通用工具脚本。配套图片资源分置于images、xngzf等文件夹，authority目录包含前端权限相关逻辑代码（如按钮显隐、菜单过滤等），支持基于角色的界面元素控制。整个包无需后端服务即可本地打开预览，适合快速搭建租赁类网站原型、教学演示、前端开发练习或作为二次开发的基础框架。

本文还有配套的精品资源，点击获取