企业官网建设流程全解析

简介：这份招聘网站源码基于Vue.js框架构建，面向具备一定前端基础、希望深入理解组件化开发与单页应用架构的开发者，可用于学习完整招聘平台的实现思路或作为二次开发起点。压缩包为zip格式，大小约1.13MB，文件总数暂未提供，从项目结构看主要包含Vue组件、路由配置、主入口脚本及静态资源等类型，覆盖src、public等标准目录。源码中体现了虚拟DOM、响应式数据绑定、指令系统与组件化开发等核心特性，并涉及Vue Router路由、Vuex状态管理、Axios请求及样式预处理等常见技术组合，便于读者对照理解页面跳转、数据同步与组件复用逻辑。目前已有1630人学习下载，适合想通过真实项目梳理Vue工程目录、依赖关系与模块划分的前端学习者参考。

1. 招聘网站源码：从一套代码到能跑起来的招聘平台，中间隔着什么

招聘网站源码这个词，搜索的人大概分两类。一类是想快速搭一个垂直招聘平台的产品负责人，手里有行业资源，缺的是能上线跑的系统；另一类是接私活或做外包的开发者，客户要一个"像某直聘那样"的站点，需要一套能改能扩的底子。这两类人的诉求其实一样：拿到源码之后，怎么让它真正跑起来、跑稳、跑出业务价值。

一套招聘网站源码通常包含几个核心模块：职位发布与检索、简历管理与投递、企业主页、即时沟通、后台审核。听起来不复杂，但真正落地时会发现，招聘场景对搜索、权限、消息实时性的要求比普通内容站高一个量级。求职者搜"某城市某薪资区间的某岗位"，背后是多重条件组合查询；企业看到简历，涉及隐私字段的脱敏和权限隔离；双方沟通，又要求消息不丢不重。

这篇笔记按"拿到源码之后怎么落地"的顺序写：先讲清一套招聘系统该有哪些模块和选型逻辑，再落到环境搭建、核心功能实现、搜索优化，最后把部署和踩坑讲透。适合手里已经有一份招聘网站源码、准备动手改造或上线的开发者，也适合正在评估要不要自研招聘系统的技术负责人。

2. 招聘网站源码的模块拆解与技术选型：哪些能省，哪些不能省

拿到一份招聘网站源码，第一件事不是急着跑起来，而是先看清楚它的模块边界和技术栈。很多源码包跑不起来，不是代码烂，是选型和你的服务器环境、业务规模对不上。这一章把招聘系统的模块拆开讲，顺带说清每个模块的选型理由。

2.1 招聘系统的六个核心模块与数据模型

一套完整的招聘网站源码，无论用什么语言写，业务上跑不出这六块：用户体系（求职者/企业/管理员三角色）、职位模块、简历模块、投递与沟通模块、搜索模块、后台管理模块。模块本身不新鲜，关键是它们之间的数据关系。

用户体系是三角色分离的。求职者和企业账号的字段差异很大，很多源码偷懒用一张 user 表加 role 字段，后期做权限时就会痛苦。常见做法是拆成user（登录凭证）、jobseeker_profile、company_profile三张表，用 user_id 关联。这样企业认证、求职者实名各自扩展字段，互不干扰。

职位和简历是一对多的投递关系。核心表大概是job（职位）、resume（简历）、application（投递记录）。投递记录这张表最容易被忽视，但它承载了状态流转：已投递、已查看、已沟通、已拒绝。状态字段设计不好，后面做消息通知和数据分析全是坑。

-- 投递记录表的核心字段设计 CREATE TABLE application ( id BIGINT PRIMARY KEY AUTO_INCREMENT, job_id BIGINT NOT NULL, resume_id BIGINT NOT NULL, jobseeker_id BIGINT NOT NULL, company_id BIGINT NOT NULL, status TINYINT DEFAULT 0 COMMENT '0已投递 1已查看 2已沟通 3已拒绝 4已录用', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_job_resume (job_id, resume_id), -- 防止重复投递 INDEX idx_company_status (company_id, status) -- 企业按状态筛选 );

这段建表语句里有两个关键点。uk_job_resume唯一索引防止同一份简历重复投同一个职位，这是业务规则落到数据库层的体现，比在应用层判断可靠。idx_company_status联合索引服务于企业端"查看我收到的所有投递"这个高频查询，没有它，企业端列表页在数据量上来后会明显变慢。

2.2 技术栈选型：为什么招聘场景不适合纯静态方案

招聘网站源码的技术栈五花八门，PHP、Java、Python、Node.js 都有。选型不看流行度，看场景匹配。招聘系统有三个特性决定了它不适合纯静态或轻量方案。

第一是搜索的复杂度。求职者搜索往往是多条件组合：城市 + 薪资区间 + 经验要求 + 学历 + 关键词。这种查询用数据库 LIKE 硬扛，数据量过万就开始卡。常见做法是引入搜索引擎，或者至少用数据库的全文索引。如果源码里搜索是WHERE title LIKE '%关键词%'，这就是第一个要改的地方。

第二是消息的实时性。招聘的核心转化发生在沟通环节，求职者和企业来回聊。轮询接口能做到，但体验差、服务器压力大。WebSocket 是更合理的选择，源码里如果用的是定时轮询，评估一下改造成本。

第三是权限的细粒度。企业只能看投递到自己职位的简历，求职者只能看自己投递的状态，管理员能看全部。这种三角色权限，用简单的角色判断能实现，但字段级脱敏（比如企业未沟通前看不到求职者手机号）需要更细的控制。

这张表不是让你一上来就上重方案，而是给出升级的触发点。小规模垂直招聘站，数据库 LIKE 加缓存能撑很久，别过度设计。

2.3 从源码到可运行：环境搭建的最小步骤

假设你拿到的是一份基于常见 Web 框架的招聘网站源码，落地第一步是让它跑起来。以 Python 系为例，通用步骤是这样。

# 1. 确认运行时版本，源码一般会在文档或依赖文件里标注 python --version # 2. 创建独立虚拟环境，避免污染系统环境 python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate # 3. 安装依赖，requirements.txt 是源码的依赖清单 pip install -r requirements.txt # 4. 配置数据库连接，通常改配置文件或环境变量 export DATABASE_URL="mysql://user:pass@localhost:3306/recruit" # 5. 初始化数据库表结构 python manage.py migrate # 6. 创建管理员账号 python manage.py createsuperuser # 7. 启动开发服务器验证 python manage.py runserver 0.0.0.0:8000

这几步里最容易翻车的是第 3 步和第 4 步。依赖装不上，多半是 Python 版本和依赖不匹配，或者某个包需要系统级库（比如图像处理、数据库驱动）。数据库连不上，先确认服务在跑、账号有权限、字符集是 utf8mb4——招聘系统里中文职位名、emoji 都可能出现，字符集不对会直接报错。

提示：源码里的配置文件通常有个.example后缀的模板，别直接改模板文件，复制一份改成实际配置，这样升级源码时不会冲突。

环境跑起来只是开始。接下来要验证核心链路：注册求职者、发布职位、投递、企业查看。这条链路走通，说明源码的基本业务逻辑是完整的，可以进入改造阶段。

3. 招聘网站源码核心功能落地：职位检索、简历投递与实时沟通

环境跑通之后，真正决定这个招聘平台好不好用的，是三个核心功能：搜索能不能快速找到匹配的职位、投递流程顺不顺、双方沟通及不及时。这一章逐个讲实现思路和关键参数。

3.1 职位多条件检索：从 LIKE 到复合索引的改造

招聘网站的搜索框，用户输入一个关键词，背后往往还带着筛选条件。原始源码如果只做了标题模糊匹配，改造的第一步是理清查询维度。

职位检索的典型条件组合：关键词（匹配职位名、公司名、描述）、城市、薪资区间、经验要求、学历要求、职位类型。这些条件里，城市和职位类型是等值查询，薪资和经验是范围查询，关键词是全文匹配。

# 职位检索的查询构造，按选择性从高到低排列条件 def search_jobs(keyword=None, city=None, salary_min=None, salary_max=None, experience=None, page=1, size=20): query = Job.query.filter(Job.status == 1) # 只查在招职位 # 等值条件优先，能快速缩小结果集 if city: query = query.filter(Job.city == city) if experience: query = query.filter(Job.experience == experience) # 范围条件，薪资字段建议存整数（单位：千元），避免浮点比较 if salary_min is not None: query = query.filter(Job.salary_max >= salary_min) if salary_max is not None: query = query.filter(Job.salary_min <= salary_max) # 关键词放最后，全文索引或搜索引擎处理 if keyword: query = query.filter(Job.title.match(keyword)) # 分页，务必限制 size 上限防止拖库 size = min(size, 50) return query.order_by(Job.refresh_time.desc()).paginate(page, size)

这段代码有几个设计决策值得说。薪资用整数存（单位千元），是因为浮点数在范围查询和排序时容易出现精度问题，招聘场景不需要精确到元。条件排列顺序按选择性从高到低，让数据库先用等值条件把结果集缩小，再做范围过滤，这是查询优化的基本思路。分页 size 强制上限 50，防止有人构造大 size 请求把数据库拖垮。

如果职位量到了几万级，Job.title.match这种全文匹配也会变慢。这时候的升级路径是引入独立的搜索服务，把职位数据同步过去，搜索走搜索引擎。但别一上来就上，先用复合索引扛，扛不住再升级。

-- 支撑上述查询的复合索引 CREATE INDEX idx_search ON job (status, city, experience, refresh_time);

这个索引的顺序有讲究：status 是必带条件放最前，city 和 experience 是高频等值条件，refresh_time 用于排序。索引不是越多越好，每个索引都会拖慢写入，招聘系统职位更新不频繁，多几个索引可以接受，但也要定期检查有没有用不上的。

3.2 简历投递与状态流转：防重复、防丢失、可追溯

投递是招聘平台的核心转化动作。看起来就是插一条记录，但要做好，得处理三件事：防重复投递、状态可流转、操作可追溯。

防重复前面用唯一索引解决了。状态流转需要一个明确的状态机，不能随便改。常见状态是：已投递 → 已查看 → 已沟通 → 已拒绝/已录用。状态只能单向流转或有限回退，不能从"已拒绝"跳回"已投递"。

# 投递状态流转，用白名单限制合法转换 ALLOWED_TRANSITIONS = { 0: [1, 3], # 已投递 -> 已查看 / 已拒绝 1: [2, 3], # 已查看 -> 已沟通 / 已拒绝 2: [3, 4], # 已沟通 -> 已拒绝 / 已录用 3: [], # 已拒绝是终态 4: [], # 已录用是终态 } def update_application_status(application_id, new_status, operator_id): app = Application.query.get(application_id) if new_status not in ALLOWED_TRANSITIONS.get(app.status, []): raise ValueError(f"非法状态流转: {app.status} -> {new_status}") # 记录操作日志，便于追溯和数据分析 log = ApplicationLog( application_id=application_id, from_status=app.status, to_status=new_status, operator_id=operator_id ) app.status = new_status db.session.add(log) db.session.commit()

状态机用白名单字典实现，比一堆 if-else 清晰，也方便扩展。操作日志表是很多源码省略的，但它在出问题时能救命——求职者说"我明明被查看了"，企业说"我没看过"，有日志就能查清。日志表还会成为后续数据分析的基础，比如统计各环节转化率。

投递之后要通知企业，通知方式看源码实现。站内信是最基本的，邮件和短信看业务需要。通知失败不能影响投递本身，所以通知逻辑要异步化，别让投递接口等通知结果。

3.3 实时沟通：WebSocket 接入与消息可靠性

招聘平台的沟通，本质是求职者和企业之间的即时消息。用 HTTP 轮询能做，但体验和服务器成本都不划算。WebSocket 是更合理的选择，但接入时要注意消息的可靠性。

// 前端 WebSocket 连接与重连逻辑 class ChatClient { constructor(userId, token) { this.userId = userId; this.token = token; this.reconnectDelay = 1000; // 初始重连延迟 1 秒 this.maxDelay = 30000; // 最大延迟 30 秒 this.connect(); } connect() { this.ws = new WebSocket(`wss://your-domain/ws?token=${this.token}`); this.ws.onopen = () => { this.reconnectDelay = 1000; // 连接成功重置延迟 this.sendPendingMessages(); // 补发断线期间的消息 }; this.ws.onmessage = (event) => { const msg = JSON.parse(event.data); this.handleMessage(msg); this.ackMessage(msg.id); // 收到后回执，服务端据此确认送达 }; this.ws.onclose = () => { // 指数退避重连，避免服务端压力 setTimeout(() => this.connect(), this.reconnectDelay); this.reconnectDelay = Math.min(this.reconnectDelay * 2, this.maxDelay); }; } }

这段前端代码的关键在重连策略和消息回执。指数退避重连是标准做法，避免服务端刚重启就被大量重连打垮。消息回执（ack）保证消息不丢——服务端发出消息后等客户端确认，没确认的存起来，客户端重连后补发。

服务端这边，消息要落库。WebSocket 是传输通道，不是存储。消息先写数据库再推送，推送失败不影响存储，用户下次上线能拉到历史消息。消息表按会话维度建索引，查询某两个人的聊天记录要快。

注意：WebSocket 连接数受服务器文件描述符限制，单机撑几千连接就要考虑优化或分布式方案。小规模招聘站单机够用，别过早分布式。

4. 招聘网站源码部署与性能优化：从能跑到跑得稳

开发环境跑通和线上稳定运行是两回事。招聘网站源码部署上线，要处理进程管理、反向代理、静态资源、数据库连接池这些工程问题。这一章讲部署的完整流程和性能优化的关键点。

4.1 生产环境部署：进程管理与反向代理配置

开发用的runserver不能上生产，它单进程、无守护、性能差。生产环境要用专业的应用服务器加进程管理器。

# 以 Gunicorn + Nginx 为例的部署流程 # 1. 安装生产级应用服务器 pip install gunicorn # 2. 用 Gunicorn 启动应用，worker 数按 CPU 核数 * 2 + 1 估算 gunicorn -w 4 -b 127.0.0.1:8000 --timeout 60 app:application # 3. 用 systemd 守护进程，保证崩溃自动重启 # /etc/systemd/system/recruit.service [Unit] Description=Recruit Platform After=network.target [Service] User=www-data WorkingDirectory=/var/www/recruit ExecStart=/var/www/recruit/venv/bin/gunicorn -w 4 -b 127.0.0.1:8000 app:application Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

worker 数的估算公式是经验值，实际要看应用是 CPU 密集还是 IO 密集。招聘系统大部分请求是数据库查询，属于 IO 密集，worker 可以适当多些，但也不是越多越好，每个 worker 都占内存。启动后观察内存和 CPU，找到合适的值。

Nginx 做反向代理，处理静态文件、SSL 终止、请求缓冲。招聘网站的简历附件、企业 logo 这些静态资源交给 Nginx 直接返回，别让应用服务器处理。

server { listen 443 ssl; server_name your-domain.com; # 静态资源直接返回，减轻应用压力 location /static/ { alias /var/www/recruit/static/; expires 30d; } # 动态请求转发给应用服务器 location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_read_timeout 60s; } # WebSocket 需要单独的 upgrade 配置 location /ws { proxy_pass http://127.0.0.1:8000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } }

WebSocket 的代理配置和普通 HTTP 不同，必须带 Upgrade 和 Connection 头，否则连接建立不起来。这是部署时最常见的翻车点之一，本地测试正常，一上 Nginx 就连不上，多半是这里漏了。

4.2 数据库连接池与慢查询治理

招聘系统的性能瓶颈，八成在数据库。连接池配置不当，高并发时连接耗尽；慢查询不治理，列表页越用越慢。

连接池的核心参数是池大小和超时。池太小，请求排队；池太大，数据库扛不住。经验值是池大小等于应用 worker 数乘以每个 worker 的并发查询数，再留点余量。

# SQLAlchemy 连接池配置示例 from sqlalchemy import create_engine engine = create_engine( "mysql://user:pass@localhost/recruit", pool_size=20, # 常驻连接数 max_overflow=10, # 峰值时额外创建的连接 pool_timeout=30, # 获取连接的超时秒数 pool_recycle=3600, # 连接回收时间，防止被数据库断开 pool_pre_ping=True, # 使用前 ping 一下，剔除失效连接 )

pool_recycle和pool_pre_ping这两个参数容易被忽略，但它们是线上稳定的关键。数据库会主动断开空闲太久的连接，应用不知道，拿到失效连接就报错。pool_pre_ping在使用前检查连接是否有效，代价很小，能避免大量偶发错误。

慢查询治理靠日志。开启数据库慢查询日志，定期分析，找出没走索引的查询。招聘系统里最常见的慢查询是职位列表和简历列表，通常是缺索引或索引没命中。

-- 开启慢查询日志 SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; -- 超过 1 秒记录 -- 分析某条查询的执行计划 EXPLAIN SELECT * FROM job WHERE city = '某城市' AND status = 1 ORDER BY refresh_time DESC;

EXPLAIN的结果重点看 type 和 key 两列。type 是 ALL 表示全表扫描，必须优化；key 显示实际用了哪个索引，如果是 NULL 说明没走索引。招聘系统的职位表，status + city + refresh_time这个复合索引能覆盖大部分列表查询。

4.3 缓存策略：哪些数据该缓存，缓存多久

招聘系统有些数据读多写少，适合缓存。但缓存不是万能药，用错了反而带来一致性问题。

适合缓存的数据：城市列表、职位分类、行业标签这类基础字典数据，变化极少，可以缓存很久。职位详情可以短时间缓存，比如 5 分钟，因为职位信息偶尔更新。不适合缓存的是投递状态、消息这类实时性要求高的数据。

# 基础字典数据缓存，设置较长的过期时间 import redis import json cache = redis.Redis(host='localhost', port=6379, db=0) def get_city_list(): cached = cache.get('city_list') if cached: return json.loads(cached) cities = City.query.filter_by(status=1).all() result = [{'id': c.id, 'name': c.name} for c in cities] # 缓存 1 小时，字典数据变化少 cache.setex('city_list', 3600, json.dumps(result)) return result

缓存更新策略上，字典数据用过期时间就够了，到期自动重新加载。职位详情这种，可以在职位更新时主动删除缓存，下次读取时重建。别用"更新缓存"的方式，并发下容易写出脏数据，删除缓存更安全。

提示：缓存雪崩是指大量缓存同时过期，请求全打到数据库。给过期时间加个随机偏移，比如 3600 加 0 到 300 秒的随机值，能有效缓解。

5. 招聘网站源码避坑指南：五个真实踩过的坑

这一章不讲新功能，专门讲踩过的坑。这些坑在招聘网站源码落地过程中出现频率很高，提前知道能省不少时间。

5.1 坑一：中文搜索用 LIKE 匹配不到预期结果

现象：求职者搜"前端开发"，明明有职位叫"前端开发工程师"，却搜不出来，或者搜出来的结果排序很乱。

原因：数据库默认的排序规则对中文分词不友好，LIKE '%前端开发%' 只能做子串匹配，无法处理分词和相关性排序。用户搜"前端 开发"带空格，或者搜"web前端"，LIKE 就匹配不上。

解决：小规模用数据库全文索引，配置中文分词器；规模大了引入独立搜索服务。改造前先确认数据库字符集是 utf8mb4，排序规则用支持中文的。如果源码里搜索逻辑是简单 LIKE，这是第一个要改的地方。

5.2 坑二：简历附件上传后文件名乱码或丢失

现象：求职者上传简历附件，企业下载时文件名变成乱码，或者文件根本下载不了。

原因：两个常见问题。一是文件名编码，中文文件名在不同系统间传输时编码不一致；二是存储路径，源码把文件存在本地某个相对路径，部署后工作目录变了，路径就失效。

解决：文件名统一用 UUID 重命名存储，原始文件名存数据库字段，下载时再还原。存储路径用绝对路径或配置项，别硬编码相对路径。生产环境建议用对象存储，本地磁盘在容器化部署时是临时的，重启就丢。

5.3 坑三：WebSocket 在 Nginx 后连不上

现象：本地开发 WebSocket 正常，部署到 Nginx 后面就连不上，浏览器控制台报连接失败。

原因：Nginx 默认不转发 WebSocket 的 Upgrade 头，需要显式配置。另外，如果用了负载均衡，多个后端实例之间没有共享会话状态，连接会飘。

解决：Nginx 配置里加proxy_set_header Upgrade和proxy_set_header Connection "upgrade"，前面部署章节已经给出。多实例场景下，消息推送需要走 Redis 发布订阅或类似机制，让所有实例都能收到消息。

5.4 坑四：投递接口被刷，产生大量垃圾投递

现象：某个职位突然收到几百条投递，内容都是乱填的，明显是脚本刷的。

原因：投递接口没有频率限制，也没有基本的风控。招聘平台是公开的，接口暴露在外，很容易被脚本盯上。

解决：投递接口加频率限制，同一用户对同一企业短时间内限制投递次数。加验证码或行为验证，增加脚本成本。投递记录里记录 IP 和 User-Agent，异常时能追溯。这些措施不能完全杜绝，但能挡住大部分低级脚本。

5.5 坑五：数据库连接数被打满，服务假死

现象：流量高峰期，应用不报错但响应极慢，数据库连接数监控显示打满。

原因：连接池配置不合理，或者有慢查询长时间占用连接。招聘系统的列表查询如果没走索引，一个慢查询占住连接，并发一上来连接就不够用。

解决：先治理慢查询，这是根本。连接池参数按前面讲的方法调整，加上pool_pre_ping剔除失效连接。监控连接池使用率，接近上限时告警。临时缓解可以调大连接池，但治标不治本。

6. 招聘网站源码的进阶玩法：把搜索和推荐做出差异

基础功能跑通、坑也踩过之后，招聘平台能不能留住用户，就看匹配效率。求职者希望快速找到合适的职位，企业希望快速找到合适的人。这一章讲两个进阶方向：搜索的相关性优化和基于行为的推荐。

搜索相关性优化，核心是让最匹配的结果排在前面。原始源码通常按发布时间排序，这对用户不友好。可以引入简单的相关性打分：关键词匹配度、职位新鲜度、企业活跃度加权。

# 简单的相关性打分，用于搜索结果重排 def relevance_score(job, keyword): score = 0.0 # 标题命中权重最高 if keyword in job.title: score += 10.0 # 描述命中权重次之 if keyword in job.description: score += 3.0 # 新鲜度：越新越高，7 天内线性衰减 days_old = (datetime.now() - job.refresh_time).days score += max(0, 7 - days_old) * 0.5 # 企业活跃度：近期有登录或发布行为加分 if job.company.last_active_at > datetime.now() - timedelta(days=3): score += 2.0 return score

这个打分函数很粗糙，但比纯时间排序好得多。权重需要根据实际数据调，标题命中的权重给高是因为用户搜的词出现在标题里，相关性最强。新鲜度衰减让老职位自然沉底，企业活跃度鼓励企业保持活跃。

推荐方向，冷启动阶段没有用户行为数据，可以先做基于内容的推荐：求职者看过或投递过的职位，提取其城市、薪资、经验等特征，推荐相似的职位。有了一定行为数据后，再引入协同过滤。

# 基于内容的相似职位推荐 def similar_jobs(job, limit=10): # 同城市、薪资区间重叠、经验要求相近的职位 candidates = Job.query.filter( Job.id != job.id, Job.status == 1, Job.city == job.city, Job.salary_min <= job.salary_max, Job.salary_max >= job.salary_min, ).limit(50).all() # 按经验要求匹配度排序 def match_score(c): s = 0 if c.experience == job.experience: s += 5 if c.category == job.category: s += 3 return s return sorted(candidates, key=match_score, reverse=True)[:limit]

推荐结果要控制多样性，别全是同一家公司的职位，否则用户会觉得平台内容单一。可以在排序后做一次打散，同一公司最多出现两个。

验证这些优化有没有效果，靠数据说话。关键指标是搜索点击率（搜索结果被点击的比例）和投递转化率（浏览职位后投递的比例）。上线前后对比这两个指标，涨了说明优化有效，没涨就回滚或继续调。

我自己的习惯是，任何优化上线前先埋点，没有数据支撑的"优化"都是玄学。招聘系统尤其如此，用户行为复杂，拍脑袋改排序往往适得其反。小流量灰度，看数据再全量，这是踩过坑之后养成的习惯。希望帮到你。

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