简介这是一份基于微信小程序的房屋租赁管理毕业设计资源面向计算机专业学生及需要掌握SSM框架与小程序整合开发的开发者适合毕业设计、课程设计或项目实训场景。系统包含管理员、中介、用户三类角色覆盖房源管理、租房订单、账单生成、用户信息维护等业务模块并提供可行性分析与数据库设计说明能帮助读者理解租赁管理系统的工程化实现。压缩包共1069个文件以Java后端源码、Vue管理端页面、微信小程序wxml/wxss文件、MySQL数据库脚本为主同时含大量png界面截图与mp4演示视频整体约59MB目录结构清晰适合按模块阅读。已有45人学习下载资源附带一键安装、运行、构建的bat脚本结合毕业论文与视频演示可降低环境搭建和二次开发门槛用于毕业设计参考或SSM小程序实战练习都很合适。1. 房屋租赁小程序不是展示页先分清租客、房东、管理员三个角色很多同学拿着“基于微信小程序的房屋租赁管理系统”这个题目开工第一步就去画首页、做房源列表最后做出来的是一个能看不能交易的展示页。问题在于租赁系统真正难的不是页面而是三个角色对着同一套房看到的状态不一样——租客看到的是“可预约”房东看到的是“审核中、已上架、已出租”管理员看到的是“待审核、违规下架”。这套状态流转才是“管理系统”的骨架。本文按微信小程序原生框架 Spring Boot MySQL 的常见技术栈讲清楚表结构怎么设计、登录与签约接口怎么写、小程序端怎么接以及上线前哪些坑必须提前趟平。适合毕业设计、课程设计也适合接私活快速交付的第一版。2. 数据模型先行房屋租赁系统的四张核心表与状态机设计这一章是整篇的定音锤。接口写错了可以改表结构错了要迁移数据重写 SQL。做房屋租赁管理系统我一般先不碰代码先画四张表user、house、appointment、contract。很多项目组喜欢往一张表里堆字段或者把“预约”和“合同”合并成一个订单表短期看起来省事一旦要算“看房转化率”“合同续租率”数据就拆不开了。下面把四张表的设计和原因一起说清。2.1 三种角色的权限边界租客、房东、管理员分别能做什么角色权限是这套系统的第一道分界线建议在写登录接口前就定死不然后面每个接口都要加一层“if 身份判断”改起来极其痛苦。按我落地的习惯权限矩阵是下面这样的操作域租客(role2)房东(role1)管理员(独立后台)房源浏览只看已上架且审核通过看自己全部房源看全部含待审核房源操作无发布、编辑、上下架审核、强制下架预约看房提交预约、取消预约确认、拒绝、完成预约查看全部预约记录合同确认合同、查看合同、发起退租起草合同、确认合同结束合同、处理纠纷实现上一张 user 表加 role 字段就够了不要给三种角色建三张用户表。三张表在“用户信息同步”上非常麻烦而且现实中一个房东自己租房住的情况也很常见——你自己有房出租同时也租别人的房双表结构直接崩。管理员不要塞进小程序端后台管理页面用 Web 做接口复用同一套 API在网关层按角色控制访问。小程序端只做租客和房东两种视图这是最省事的切法。2.2 核心数据表结构用户、房源、预约、合同四张表直接用我最常用的一套建表 SQL字段按业务最小集来不堆冗余-- 用户表 CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, openid varchar(64) NOT NULL COMMENT 微信openid唯一标识, nickname varchar(50) DEFAULT COMMENT 微信昵称, phone varchar(20) DEFAULT COMMENT 手机号签约时必填, role tinyint(4) NOT NULL DEFAULT 2 COMMENT 1房东 2租客, avatar varchar(255) DEFAULT , create_time datetime DEFAULT CURRENT_TIMESTAMP, deleted tinyint(1) DEFAULT 0, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 房源表 CREATE TABLE house ( id bigint(20) NOT NULL AUTO_INCREMENT, landlord_id bigint(20) NOT NULL COMMENT 房东user.id, title varchar(100) NOT NULL, cover varchar(255) NOT NULL COMMENT 封面图URL, images json DEFAULT NULL COMMENT 轮播图URL数组, area decimal(6,2) DEFAULT NULL COMMENT 面积㎡, layout varchar(20) DEFAULT COMMENT 户型如两室一厅, rent decimal(10,2) NOT NULL COMMENT 月租金, deposit decimal(10,2) DEFAULT NULL COMMENT 押金, address varchar(255) NOT NULL COMMENT 小区楼栋门牌, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0草稿 1上架 2已出租 3下架, audit_status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待审核 1通过 2拒绝, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_landlord (landlord_id), KEY idx_status (status,audit_status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 预约看房表 CREATE TABLE appointment ( id bigint(20) NOT NULL AUTO_INCREMENT, house_id bigint(20) NOT NULL, tenant_id bigint(20) NOT NULL, visit_time datetime NOT NULL COMMENT 计划看房时间, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待确认 1已确认 2已取消 3已完成, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_house (house_id), KEY idx_tenant (tenant_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 合同表 CREATE TABLE contract ( id bigint(20) NOT NULL AUTO_INCREMENT, appointment_id bigint(20) NOT NULL COMMENT 签约关联的预约记录, house_id bigint(20) NOT NULL, tenant_id bigint(20) NOT NULL, landlord_id bigint(20) NOT NULL, start_date date NOT NULL, end_date date NOT NULL, rent decimal(10,2) NOT NULL, deposit decimal(10,2) NOT NULL, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待签署 1生效中 2已结束 3已解约, file_url varchar(255) DEFAULT COMMENT 已生成的合同PDF地址, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有几个字段取舍值得展开。第一个是 house.images 用 json 存数组不要为“多图”单独建一张附件表。小程序端一次最多传 9 张图json 完全够用还能避免一次房源详情要查两张表的麻烦。第二个是 status 和 audit_status 必须分开这是两根完全独立的轴审核是“能不能对外展示”上下架是“房东是否愿意出租”合在一个字段里会出现“审核拒绝”和“手动下架”互相覆盖的脏数据。第三个是 deleted 逻辑删除字段房源下架不等于删除管理员误下架要能一键恢复物理删除在这类系统里是给自己找麻烦。2.3 状态流转房源、预约、合同三条状态机表结构定完后最要紧的是把状态流转规则写明白否则前端按钮的“置灰/可点”完全没法判断。下面是三条状态机对象状态值与含义触发动作房源0草稿→1上架→2已出租→3下架提交审核 / 审核通过 / 签约成功 / 房东手动或管理员违规下架预约0待确认→1已确认→2已取消→3已完成房东确认 / 双方任一方取消 / 看房结束合同0待签署→1生效中→2已结束→3已解约双方确认签署 / 租期到期 / 违约终止重点关注一点预约和合同不要合并成一张订单表。很多同学觉得“预约看房成功后就直接签约”其实是两步业务——看房是意向签约是成交中间还隔着线下谈价。把预约和合同拆开好处是看房转化率、合同履约率可以分开统计而且预约表的状态只管到“看房完成”后续合同表的生命周期独立演进不会被一个订单对象绑死。我见过最难受的改法是后来想加“租金减免”字段结果发现合同和预约混在同一张表里连加字段都不知道加在哪一端。3. 后端接口实现微信登录、房源发布与签约下单的 Spring Boot 落地表结构定了后端就顺了。这一章挑三个最影响交付的接口讲登录、图片上传、签约。一是这三个接口最容易在小程序端出问题二是它们的写法决定了后面所有接口的骨架。技术栈用 Spring Boot MyBatis-Plus这是目前做这类管理系统最常见的组合。3.1 微信登录的完整链路code 换 openid再下发自定义 token小程序端 wx.login 拿到的 code 是五分钟有效的一次性凭证后端拿 code 去微信接口换 openid。注意 openid 是用户在小程序里的唯一身份但后端不要直接把 session_key 下发到前端那东西一旦泄露理论上可以伪造会话。正确做法是后端自己发一个 token放到 Redis 里设 7 天过期PostMapping(/login) public Result login(RequestBody LoginDTO dto) { String url https://api.weixin.qq.com/sns/jscode2session?appid appId secret appSecret js_code dto.getCode() grant_typeauthorization_code; String resp restTemplate.getForObject(url, String.class); JSONObject obj JSONObject.parseObject(resp); if (obj.getString(openid) null) { return Result.fail(登录失败 obj.getString(errmsg)); } String openid obj.getString(openid); User user userMapper.selectOne(new LambdaQueryWrapperUser() .eq(User::getOpenid, openid)); if (user null) { user new User(); user.setOpenid(openid); user.setRole(2); // 默认租客 userMapper.insert(user); } String token UUID.randomUUID().toString().replace(-, ); redisUtil.set(login:token: token, String.valueOf(user.getId()), 7 * 24 * 3600); return Result.ok(LoginVO.builder() .token(token) .role(user.getRole()) .nickname(user.getNickname()) .phone(user.getPhone()) .build()); }逻辑很简单先拿 code 换 openid查 user 表没有就自动注册有就更新登录状态最后返回自定义 token。前端后续请求都带这个 token后端根据 token 从 Redis 取出 userId再去查角色。这里我一般会在LoginVO里把 role 一起返回前端才能决定跳转到“租客首页”还是“房东工作台”。提示wx.getPhoneNumber 目前要求小程序已完成企业主体认证个人开发者的小程序调用会直接报错。所以这个系统里手机号我用表单录入签约前校验手机号非空不做一键授权。3.2 房源发布与图片上传文件存储的大小、格式与命名规范房源发布的第一步是传图片。小程序端用 wx.chooseMedia 拿到临时文件路径再通过 wx.uploadFile 上传。后端接口按下面的写法能挡住 90% 的脏数据PostMapping(/file/upload) public Result upload(RequestParam(file) MultipartFile file) throws IOException { if (file.isEmpty()) { return Result.fail(文件不能为空); } if (file.getSize() 5 * 1024 * 1024) { return Result.fail(图片不能超过5MB); } String suffix StringUtils.getFilenameExtension(file.getOriginalFilename()); if (!Arrays.asList(jpg, jpeg, png, webp).contains(suffix)) { return Result.fail(不支持的图片格式); } String key house/ UUID.randomUUID() . suffix; ossClient.putObject(rental, key, file.getInputStream()); return Result.ok(https://your-bucket.oss-cn-hangzhou.aliyuncs.com/ key); }参数设计的重点有三个大小限制 5MB 对应小程序端 wx.chooseMedia 的 sizeType 参数超过这个值上传耗时会长到用户直接放弃格式限定 jpg/png/webpgif 这类动图在列表页非常吃性能建议直接拒绝文件命名用 UUID 而不是原名否则两个用户都传1.jpg后传的会覆盖先传的这是文件服务最常见的翻车点。上传成功后返回的永久 URL 要存到 house.images 字段里发布房源接口只需要接收 cover 和 images 两个字符串cover 取第一张图。3.3 预约与签约接口条件更新才能防止重复下单预约接口本身不复杂插入一条 appointment 记录即可但前置校验要做扎实PostMapping(/appointment) public Result createAppointment(RequestBody AppointmentDTO dto) { House house houseMapper.selectById(dto.getHouseId()); if (house null || !1.equals(String.valueOf(house.getStatus()))) { return Result.fail(房源不可预约); } Appointment apt new Appointment(); apt.setHouseId(dto.getHouseId()); apt.setTenantId(currentUserId()); apt.setVisitTime(dto.getVisitTime()); apt.setStatus(0); appointmentMapper.insert(apt); return Result.ok(apt.getId()); }这里 status 只允许为 1上架且审核通过的房源被预约。签约接口才是真正考验功底的地方两个租客同时点“签约”如果代码先selectById看 status 再updateById改成已出租两个请求都读到“可租”最后就会生成两份合同。正确写法是条件更新PostMapping(/contract/sign) public Result sign(RequestBody SignDTO dto) { // 先把房源从“上架”改成“已出租”条件带上 status1 int rows houseMapper.update(null, new LambdaUpdateWrapperHouse() .eq(House::getId, dto.getHouseId()) .eq(House::getStatus, 1) .set(House::getStatus, 2)); if (rows 0) { return Result.fail(房源已被租出请刷新后再看); } // 房源抢占成功后再创建合同记录 Contract contract new Contract(); contract.setHouseId(dto.getHouseId()); contract.setTenantId(dto.getTenantId()); contract.setLandlordId(dto.getLandlordId()); contract.setAppointmentId(dto.getAppointmentId()); contract.setStartDate(dto.getStartDate()); contract.setEndDate(dto.getEndDate()); contract.setRent(dto.getRent()); contract.setDeposit(dto.getDeposit()); contract.setStatus(0); contractMapper.insert(contract); return Result.ok(签约成功等待房东确认); }condition update 的精髓在于数据库层面的原子性——UPDATE house SET status2 WHERE id? AND status1这条语句在上架房源只有一条时并发请求只会有一个影响行数为 1另一个是 0从源头堵住超卖。如果还想更稳可以在 contract 表给 house_id 加唯一索引双保险。这个写法同样适用于预约的取消、管理员的下架凡是涉及“状态跳变”的接口都别用先查后改。4. 小程序前端落地请求封装、房源列表与预约表单的核心代码后端接口就绪后小程序端主要做三件事统一请求封装、列表分页、表单提交。很多毕设代码把 wx.request 写在每一个页面里token 要重复传出错要重复处理改一个接口地址要全局搜索替换。这一章直接给你一套能复用的骨架。4.1 request.js 封装token、401 与 baseUrl 的统一管理utils/request.js 是全项目最值得先写的文件const BASE_URL https://api.example.com function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method: method.toUpperCase(), data, header: { Content-Type: application/json, token: wx.getStorageSync(token) || }, success(res) { if (res.statusCode 401) { wx.removeStorageSync(token) wx.navigateTo({ url: /pages/login/login }) reject(res.data) return } if (res.data.code ! 0) { wx.showToast({ title: res.data.msg, icon: none }) reject(res.data) return } resolve(res.data) }, fail(err) { wx.showToast({ title: 网络异常请重试, icon: none }) reject(err) } }) }) } module.exports { request, BASE_URL }这段代码做了几件小事所有请求自动带 token遇到 401 清掉登录态并跳转登录页后端约定的 code0 为成功业务错误统一 toast。这里有个经验token 一定要从 storage 读不要从 globalData 读。小程序冷启动时 globalData 是空的而 storage 是持久化的从 storage 读才能保证用户重启小程序后登录态还在。4.2 首页与房源列表分页加载与触底刷新首页房源列表不做分页一次拉全量列表房源稍微多一点 setData 的数据量就会让页面卡顿。标准做法是 page 和 pageSize 分页触底加载下一页Page({ data: { list: [], page: 1, pageSize: 10, loading: false, finished: false }, onLoad() { this.loadList(true) }, onReachBottom() { if (!this.data.loading !this.data.finished) { this.loadList(false) } }, loadList(reset) { const page reset ? 1 : this.data.page 1 this.setData({ loading: true }) request(/house/list?page${page}pageSize${this.data.pageSize}) .then(res { const records reset ? res.data.records : this.data.list.concat(res.data.records) this.setData({ list: records, page, finished: records.length res.data.total }) }) .finally(() { this.setData({ loading: false }) }) } })参数说明reset 为 true 时拉第一页并重置列表适用于下拉刷新为 false 时追加下一页。finished 的判断用总条数 total 和当前列表长度比较防止最后几页反复请求空数据。这个模式所有列表页都能套收藏列表、我的房源、合同列表都复用同一套逻辑。4.3 房源详情与预约表单picker 日期、radio 租期与导航栏高度详情页的预约表单涉及三个小程序常用控件。日期选择用 picker modedate租期选择用 radio-group这是最顺手的组合picker modedate start{{today}} bindchangeonDateChange view classpicker-value{{visitDate || 请选择看房日期}}/view /picker日期选择拿到的是2024-06-01这种字符串但 iOS 的 JavaScriptCore 不认这个格式直接new Date(2024-06-01)会得到 Invalid Date。正确的做法是回填前先替换onDateChange(e) { // iOS 不认 yyyy-MM-dd统一转成 yyyy/MM/dd const date e.detail.value.replace(/-/g, /) this.setData({ visitDate: date }) }这段代码就是“微信小程序顶部导航栏高度”这个老问题之外第二个 iOS 适配的典型坑。导航栏高度如果用了自定义导航栏也别写死不同机型胶囊按钮位置不同正确计算方式是读取胶囊布局信息const rect wx.getMenuButtonBoundingClientRect() const windowInfo wx.getWindowInfo ? wx.getWindowInfo() : wx.getSystemInfoSync() const navHeight (rect.top - windowInfo.statusBarHeight) * 2 rect.height租期选择用 radio-group年付、月付、押一付三这类选项都适合单选radio-group classrent-type bindchangeonRentTypeChange label classradio-item radio value12 checked /年付 /label label classradio-item radio value1 /月付 /label /radio-groupradio 在小程序里默认样式很丑一般会通过 cover 或自定义样式把圆点和文字间距拉开。业务上建议给 radio 的 value 直接传数字字符串后端接收后强转避免“年付”这种中文值传到数据库还要再映射一次。4.4 我的页面按角色渲染不同菜单登录接口返回 role 字段后前端就要做分支渲染。我的页面用 wx:if 按角色显示不同入口比写两套页面省事太多view classmenu-group wx:if{{userInfo.role 1}} cell title发布房源 bindtapgoPublish/cell cell title我的房源 bindtapgoMyHouse/cell cell title预约管理 bindtapgoAppointmentManager/cell /view view classmenu-group wx:if{{userInfo.role 2}} cell title我的预约 bindtapgoMyAppointment/cell cell title我的合同 bindtapgoMyContract/cell cell title我的收藏 bindtapgoFavorite/cell /view这里有一个容易被忽略的细节wx:if 判断的是变量类型后端返回的 role 是 number但某些情况下 JSON 解析会变成字符串role 1永远为 false。我在联调时吃过这个亏后来统一在后端返回 int前端用Number(userInfo.role) 1做判断彻底根除类型问题。角色分支的登录态校验也要做在 onShow 里因为用户可能在小程序后台切换账号onLoad 只在首次加载执行一次onShow 每次进入页面都会执行。5. 避坑记录房屋租赁小程序最常见的 5 个翻车现场这一章写我做过、带人做过这类项目后沉淀下来的踩坑记录全部是真实复现过的场景。按“现象 → 原因 → 解决”三条写方便你对照排查。5.1 环境与文件类真机联调最容易踩的两个坑坑 1开发工具里接口正常真机一打开就 request:fail现象开发者工具里预览、调试、网络面板都正常扫码真机运行后白屏控制台打 request:fail。原因接口地址写成了http://localhost:8080。开发者工具的 localhost 指向你电脑真机的 localhost 指向手机自己手机当然连不上。这是“微信小程序开发工具接口访问正常 真机接口访问失败”最常见的原因。解决把 BASE_URL 改成电脑的局域网 IP比如http://192.168.1.100:8080手机和电脑连同一个 WiFi 再试。在开发者工具“详情 → 本地设置”里勾选“不校验合法域名”否则真机请求会被拦。正式上线前再去公众平台配置 HTTPS 的 request 合法域名这一步别拖到审核前一天。坑 2图片上传成功后列表全裂图现象发布房源时缩略图能预览发布成功后回到列表封面图全是灰色占位块。原因上传时没有处理后端返回的永久 URL而是把wx.chooseMedia返回的tempFilePath直接存进了 house 表。tempFilePath 是小程序运行期间的临时文件路径页面关掉或小程序退出后就失效了。解决wx.uploadFile 成功后用返回的永久 URL 覆盖临时路径等所有图片传完再提交房源表单。封面图和轮播图统一存后端返回 URL 数组的 JSON 字符串列表页不要再拼接任何本地路径。5.2 数据与状态类登录态、并发签约与日期解析坑 3登录成功后重启小程序又回到登录页现象用户首次登录后填完预约信息退出小程序再进来要求重新登录。原因登录成功后的 token 只存在当前页面的 data 里没有写入 storage。小程序冷启动后 token 丢失request 拦截器拿不到有效凭证被 401 打回登录页。解决登录接口返回 token 后立刻wx.setStorageSync(token, token)。request.js 里从 storage 读取而不是从 globalData 读取见 4.1 节代码。另外登录页要做静默登录进入小程序先调一次 wx.login 换 code后端自动注册用户无感知地完成登录而不是一进来就弹授权框。坑 4一套房被两个租客同时签约成功现象两个租客同时点“签约”房东后台看到两份合同房源状态却只有一个。原因签约接口用了“先查状态再更新”的写法。两个请求都查到了 status1然后分别执行 updateById把状态从 1 改成 2数据库层面没有任何约束拦住第二次写入。解决改用条件更新UPDATE house SET status2 WHERE id? AND status1影响行数为 0 就直接提示“房源已被租出”。合同表再给 house_id 加唯一索引双重保险。具体实现见 3.3 节代码这个写法同样适用于预约确认和管理员强制下架凡是状态跳变接口都必须条件更新。坑 5日期字段在 iOS 上显示 Invalid Date现象微信开发者工具里一切正常iPhone 上合同开始日期显示 NaN 或 Invalid Date。原因picker modedate 返回的是2024-06-01格式字符串iOS 的 JavaScriptCore 不认这种格式new Date(2024-06-01)解析失败。解决取值后先e.detail.value.replace(/-/g, /)再处理数据库和接口层面统一用时间戳或yyyy/MM/dd格式。日期比较也不要直接拿字符串比大小转成时间戳再比。后端返回日期给前端时建议统一返回yyyy-MM-dd HH:mm:ss字符串前端展示前再格式化。提示还有一个更隐蔽的日期坑是时区。数据库存的是北京时间接口返回给小程序后没转时区合同起止日会平白少 8 小时。如果你用时间戳存 contract 的 start_date 和 end_date记得在服务端先转成东八区再返回。6. 上线前验证真机联调、体验版与审核注意的三个细节系统功能写完后最怕的不是逻辑 bug而是“开发者工具里好好的一上真机就露馅”。这一章给你三个上线前必做的动作省得审核被驳回两次才反应过来说明书写得再好也没用。发布体验版前跑通三个场景。第一个是弱网场景开发者工具里把网络切到弱网看房源列表是否出现加载兜底接口超时有没有提示文案。第二个是多角色联调准备一个房东账号一个租客账号完整走一遍“发布房源 → 管理员审核 → 租客预约 → 房东确认 → 双方签约”的链路中间任何一步卡住先查状态字段是否符合预期。第三个是新设备首启用一个之前没登录过的手机号扫码确认静默登录能自动完成不要第一步就弹授权框把人吓跑。审核容易被拒的两个点要提前处理。类目选择上房屋租赁类目属于房产行业个人主体往往缺少资质文件。常见做法是把类目选到“生活服务”服务描述写“个人房东房源信息发布与管理”轻量很多。内容审核上测试账号里不要放“月租 500 市中心精装”这类明显虚假的房源审核员会逐条看数据真实性最好用几套带真实地址脱敏的房源做演示。整个业务流程的按钮都不能是“开发中”占位哪怕功能简单也要有一个可用版本。状态变更通知是提升体验的小技巧。房源被下架、预约被拒绝、合同即将到期这些状态变化用户自己发现不了。最简单的方案是小程序内轮询关键状态接口配合服务端判断后通过订阅消息推送。个人开发者申请订阅消息模板时选择“预约提醒”和“业务通知”两个模板足够覆盖租赁场景。注意订阅消息是有次数限制的别把模板消息当营销通道刷。我之前上线过一版带后台管理的租赁小程序最大的教训就是上真机前没做新设备全流程测试。当时图片上传成功但列表页的 src 拼接漏了一段路径审核员打开看到全部裂图连拒两次。后来养成一个习惯每次发布体验版前用一个新手机号从头走一遍完整流程专门盯图片、日期、按钮置灰这三个细节从此再没在审核环节翻过车。这条习惯今天也分享给你希望帮到你。本文还有配套的精品资源点击获取