一、做代理和跑爬虫，VPS 和普通云服务器到底有什么不一样
表面上看，买一台 VPS 装个代理软件就能跑，但真按这个思路去落地，通常跑不到第三天就会遇到两个问题：IP 被目标站点风控盯上，以及流量成本失控。普通建站型 VPS 的选型逻辑是"页面能打开就行"，而做代理和爬虫这台机器的价值完全建立在两个指标上：出口 IP 的信誉评分，以及单位时间能稳定承载的请求并发数。
延伸对照：interserver 的公开机型与线路说明，可结合本节的判断标准自行核对。
先说清楚这台机器在架构里扮演的角色。做代理时，VPS 是流量的中转节点：客户端把请求交给它，它从自己的出口 IP 发起对外连接，把响应原路返回。做爬虫时，VPS 既是抓取发起端，也是任务调度端，你会在上面跑 Headless 浏览器或者直接用 HTTP 客户端。两个场景对机器的要求是重叠但不完全一致的，代理更吃带宽和 IP 信誉，爬虫更吃 CPU、内存和并发控制能力。
一个必须先摆正的事实是：能连上不等于能用。VPS 的 IP 属于数据中心广播段，这类段在全球各大平台的反滥用体系里被系统性标记，平台不需要识别出"这是代理"，只要发现某个数据中心段在短时间内访问量异常、请求头模式单一、行为轨迹非人类，就能直接降权或拦截。所以真正的门槛不在技术链路，在于你的出口段在目标平台眼里是不是"正常人"。
第二个事实是并发和 IP 的绑定关系比想象中更紧。很多人在选型时按"我这台机器带宽够跑多少 Mbps"来推算并发，但真正限制你的往往是 IP 侧的速率限制。同一台机器、同一个 IP，从 1 并发变成 20 并发，触发风控的概率不是线性上升，而是有一个明显的拐点，过了这个点之后你会看到错误率曲线断崖式上升，而不是缓慢变差。
第三个事实是成本结构完全不同。建站型 VPS 的流量成本可以忽略，因为用户量少；做代理的 VPS 是流量消耗大户，一个中等规模的抓取任务每月跑出的流量可能达到几百 GB，把这些流量摊进每 GB 成本之后，选型逻辑会从"配置够用"变成"带宽单价够低"。这也解释了为什么很多人在做爬虫时优先考虑大流量不限量的机型，而不是高配小带宽。
还有一个常被忽略的差异是稳定性要求。建站业务宕机半小时影响的是流量，而爬虫业务宕机意味着任务窗口错失、账号被判定异常、已抓到的数据断档。所以做代理和爬虫的机器，备份、快照、快速重装、自动重启这些运维能力的权重，比纯配置参数高得多。
二、机房 IP 和住宅 IP，差别到底在哪一层
两者的差别不在带宽、不在延迟，而在"地址是怎么来的"以及"平台怎么给这类地址打分"。
延伸对照：itldc 的公开机型与线路说明，可结合本节的判断标准自行核对。
数据中心 IP 是机房向运营商批量申请的地址段，段内可以划分出成百上千个地址分配给不同机器。这些段的特点是用户数量密集、用途单一、历史上容易承载批量注册、垃圾邮件、代理滥用等行为。平台的风控数据库里，这类段的基线信誉分普遍低于运营商面向家庭用户分配的住宅段。
住宅 IP 来自运营商的动态地址池或家庭宽带的固定分配，同样一段地址背后是分散的终端用户，行为模式多样，天然具备"人味儿"。这是住宅 IP 在风控评分上占优的根本原因。
但这里有一个必须讲清楚的现实：住宅 IP 资源不是普通 VPS 商家能稳定提供的。它通常来自动态住宅代理服务，价格是数据中心 VPS 的数倍到数十倍，来源合规性参差不齐，稳定性也无法与自购机器相比。所以对于绝大多数个人开发者和小团队，用 VPS 跑代理和爬虫是唯一现实的选择，关键问题不是"怎么搞到住宅 IP"，而是"怎么在数据中心 IP 的条件下把成功率做上去"。
数据中心 IP 之间也有差异。不同机房、不同段的历史用途不同，有的段常年干净，有的段因为长期被代理服务占用而信誉极差。同一家商家相邻的两台机器拿到不同段的情况非常普遍。所以判断标准应该精确到"这一台机器的这个 IP 段"，而不是笼统的"这个机房行不行"。
拿到机器后第一时间做归属与信誉自查：
# 查看出口 IP 的归属段、类型与运营商
curl -s ipinfo.io/json | head -30
# 查看自治域与段信息
whois $(curl -s https://api.ipify.org) | grep -Ei 'netname|orgname|country|descr'
# 连续查询确认出口是否稳定
for i in $(seq 1 10); do curl -s https://api.ipify.org; echo; sleep 1; done返回结果里重点看三处：type 字段是 hosting 还是 ISP，hosting 就是数据中心段；org 或自治域对应的运营商；以及该段在滥用数据库里的历史记录。一个被大量标记过的段，即使你只用来做正常的接口调用，也可能在你完全不知情的情况下被降权。
还要说清楚一点：检测网站给出的评分只是参考，不是判决。真正有意义的验证是用你自己的目标站点做小规模实测，抓十来个页面看看返回的是正常内容、验证码还是拒绝页，比任何第三方评分都准。
三、并发和带宽怎么换算，一个 IP 能扛多少请求
并发能力的上限由三个环节共同决定：IP 侧的速率限制、机器的资源瓶颈、以及带宽。多数情况下 IP 侧的限制先到，所以先算带宽，再做 IP 侧的压测验证。
延伸对照：iwebfusion 的公开机型与线路说明，可结合本节的判断标准自行核对。
带宽侧的算法很简单。每个请求按平均响应体 200 KB 算，一个并发连接如果每秒完成 2 次请求，消耗的带宽就是 200 KB × 2 × 8 ≈ 3.2 Mbps。100 并发就是这个数的 100 倍，也就是 320 Mbps。这就是为什么高并发爬虫必须先算带宽，再去选机型。
# 用 awk 估算：并发数 × 每请求响应体(KB) × 每秒请求数 = 所需 Mbps
awk 'BEGIN{c=100;kb=200;rps=2;printf "约需带宽: %.0f Mbps\n", c*kb*rps*8/1024}'
# 反向：已知带宽 500 Mbps，问单请求 200KB 时能支撑多少并发（按 2 rps）
awk 'BEGIN{mb=500;kb=200;rps=2;printf "理论并发: %d\n", mb*1024/(kb*rps*8)}'这个理论值是上限，实际能跑到七成就不错了，因为超售、协议开销和重传都会吃掉一部分。要拿到真实数字，必须自己压测：
# 服务端起一个返回固定大小的接口
python3 -m http.server 8000 --bind 0.0.0.0
# 客户端用 wrk 压测 30 秒，32 条连接
wrk -t4 -c32 -d30s http://你的VPS_IP:8000/
# 观察并发爬取时的资源占用
htop判读方式：先看吞吐是否随并发数线性上升，如果加并发吞吐不涨，说明瓶颈在带宽或 IP 限速，而不是 CPU。再看错误率，连接被重置、返回 429、返回验证码页面都属于 IP 侧限流的信号，这时继续加并发只会让情况更糟。
再强调一次那个拐点。实践中更稳妥的做法是给每个 IP 设一个保守的并发上限，比如 3 到 8 个并发请求，然后用轮换把总并发分摊到多个 IP 上，而不是把一个 IP 压到报错。这个策略同时降低了单个 IP 的关联度。
代理场景的并发模型略有不同。代理的瓶颈往往在长连接的保持能力上，一个 SOCKS5 或 HTTP 代理在承载大量长连接时，对文件描述符和连接跟踪表有额外要求：
# 查看文件描述符上限
ulimit -n && cat /proc/sys/net/ipv4/ip_local_port_range
# 临时提高并检查当前占用
ulimit -n 65535
ss -s四、被封之后是什么表现，怎么判断是 IP 被盯上还是程序出错
这是最耗时间的一个环节，因为被封的表现和程序 bug 的表现高度相似。学会区分，能省下大量瞎猜的时间。
延伸对照：racknerd 的公开机型与线路说明，可结合本节的判断标准自行核对。
第一类典型信号是 HTTP 状态码异常。正常请求返回 200，突然间大量返回 429，也就是限流。429 是最友好的信号，说明平台判定你在超出速率但还没有把你列入黑名单，此时降速就能恢复。403 或者 503 有时是风控拦截，有时只是页面结构变化，需要看响应体内容才能区分。
第二类信号是响应内容变了但状态码仍然是 200。这类情况最难发现。返回的内容从正常 HTML 变成了验证码页面、登录墙、或者一个几乎空白的骨架页。所以抓取程序必须做内容校验，而不是只看状态码：
# 检查响应体里是否出现了风控特征词
curl -s -A "Mozilla/5.0" "https://目标站点/页面" | grep -Eo 'captcha|verify|challenge|滑动验证|人机验证' | sort -u
# 对比响应体长度：正常页面和验证页的长度差异通常很明显
curl -s -o /dev/null -w "%{size_download}\n" -A "Mozilla/5.0" "https://目标站点/页面"第三类信号是跳转行为的改变。请求被 302 重定向到一个不属于目标站点主域名的地址，尤其是跳到登录页或者验证页，这时基本可以确认是账号或 IP 层面的拦截。
第四类信号是 TLS 层被断开，连接在握手阶段被重置，这类情况往往发生在请求头特征过于明显的场景，比如 UA 缺失或者用了默认的库标识。
排查时的正确顺序是：先换 IP 验证，再换请求头验证，最后才怀疑代码。实际操作上，先在另一台机器用完全相同的脚本跑一次，如果那台正常，就是 IP 问题；如果两台都失败，就不是 IP 的问题。
还有一个必须提前做的准备是记录基线。正常状态下把关键指标记录下来，比如某个页面的响应长度、标题特征、正常情况下的状态码分布。等出问题的时候，对比基线能快速缩小范围：
# 记录基线：状态码、响应大小、耗时
curl -s -o /dev/null -w "code=%{http_code} size=%{size_download} time=%{time_total}\n" \
-A "Mozilla/5.0" "https://目标站点/页面"
# 做一次多 URL 的健康检查
for u in "https://目标站点/a" "https://目标站点/b"; do
curl -s -o /dev/null -w "$u -> %{http_code} %{time_total}s\n" -A "Mozilla/5.0" "$u"
done五、指纹隔离与代理池，普通 HTTP 头为什么不够用
现在主流的反爬体系已经不看单个请求头了，它看的是整个浏览器环境的一致性。所谓指纹，指的是一组能唯一刻画客户端特征的信号集合：User-Agent、请求头顺序、Accept-Language、Sec-CH-UA 系列、TLS 握手指纹、HTTP/2 设置、Cookie 行为、鼠标与滚轮轨迹、Canvas 与 WebGL 渲染指纹。
延伸对照：cloudcone 的公开机型与线路说明，可结合本节的判断标准自行核对。
只用 curl 加一个 User-Agent 的做法，在任何有风控的站点面前都是裸奔。判断某一层防护有没有生效，最直接的办法是把你的请求特征和一个真实浏览器对比：
# 用真实浏览器的请求头做一次对照
curl -s -o /dev/null -w "%{http_code}\n" \
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36" \
-H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8" \
-H "Accept-Language: zh-CN,zh;q=0.9,en;q=0.8" \
-H "Sec-Ch-Ua: \"Chromium\";v=\"131\", \"Not_A Brand\";v=\"24\"" \
-H "Sec-Ch-Ua-Mobile: ?0" \
-H "Sec-Ch-Ua-Platform: \"Windows\"" \
-H "Upgrade-Insecure-Requests: 1" \
"https://目标站点/页面"关键在于一致性。UA 声称是 Windows 上的 Chrome，但请求头里没有任何 Chrome 特有的头，或者 Sec-CH-UA 平台写成了 macOS，这就是典型的矛盾特征，在几秒内就能被判定。
代理池的设计目标是让每个身份有稳定且独立的一整套特征，而不是简单地轮换 IP。轮换 IP 但复用同一套请求头，等于把所有行为都标记在同一个身份上，风险更高。合理的结构是：
| 层次 | 隔离对象 | 实现方式 | 常见错误 |
|---|---|---|---|
| 网络层 | 出口 IP | 代理池按任务分配 | 同一 IP 并发过高被限速 |
| 协议层 | TLS/HTTP2 指纹 | 固定客户端版本库 | 库版本与 UA 声明不匹配 |
| 头部层 | 请求头组合 | 每个身份一套固定头 | 头部顺序随机化反而异常 |
| 会话层 | Cookie 与登录态 | 每身份独立存储 | 多身份共用 Cookie 罐 |
| 行为层 | 访问节奏与路径 | 合理延迟与随机停顿 | 每秒固定 N 次完全一致 |
在真实的项目里，实现完整浏览器指纹隔离的门槛不低，主流选择有两条路。一条是基于 Playwright 或 Puppeteer 的真实浏览器上下文，每个身份一个独立的浏览器上下文，指纹自然一致；另一条是基于指纹伪装库的轻量方案，模拟浏览器的 TLS 握手与 HTTP2 设置，但需要跟着目标站点的检测升级不断维护。
无论走哪条路，有一条纪律是通用的：身份与 IP 的绑定要稳定，一个身份固定用同一类出口，不要每次请求都换。频繁切换本身就是一个异常信号。
六、成本核算，怎么算清每一条有效数据的真实价格
代理和爬虫的账不能按月费算，必须折算到"每一条有效数据"或者"每 GB 有效流量"。这个折算能把很多看起来划算的方案淘汰掉。
延伸对照：digitalocean 的公开机型与线路说明，可结合本节的判断标准自行核对。
先算流量侧的账。假设你的爬虫每个页面平均 200 KB，每小时抓取 5000 个页面，一个月按 30 天算：
# 月流量估算：页数 × 大小 × 天数
awk 'BEGIN{pages=5000;kb=200;days=30;gb=pages*kb*days/1024/1024;printf "月流量约 %.1f GB\n", gb}'
# 每 GB 成本（示例月费 45 美元、额度 2048 GB）
awk 'BEGIN{printf "标价每GB: $%.4f\n", 45/2048}'
# 有效率 40% 时，每 GB 有效流量的真实成本
awk 'BEGIN{printf "有效每GB: $%.4f\n", 45/2048/0.4}'有效率这个数字是整套账里最关键的一个变量。抓取一万条数据，如果只有四千条是有效可用的，那另外六千条对应的流量和 IP 消耗全是浪费。提升有效率的手段包括：更准的选择器、更合理的重试策略、更少的无效请求。这些改进带来的收益远大于换一台更便宜的机器。
再算 IP 侧的隐形成本。IP 被封之后，换 IP、重新测试、调整策略所花的人工时间，如果按两小时计，就相当于摊薄到每一个有效数据上的额外成本。在中小规模任务里，这一项经常超过机器本身的费用。
还要算合规成本。抓取如果需要登录态，就涉及账号，而账号本身是有资产价值的；批量注册的账号被平台封禁，前期投入全部作废；目标站点的服务条款如果禁止自动化访问，那么即使技术上可行，规模化执行也可能带来法律与商业风险。这部分不是技术问题，但它常常是整个项目最大的成本项。
价格区间的估算如下，用于判断量级，具体配置与报价以各商家官网当日报价为准：
| 场景 | 常见区间（估算） | 主要成本项 | 优化方向 |
|---|---|---|---|
| 低频小规模抓取 | 30–80 元/月 | 机器 + 少量流量 | 控制请求频率，提升有效率 |
| 中等规模定时抓取 | 80–200 元/月 | 机器 + 数 TB 流量 | 大流量机型 + 缓存复用 |
| 高频多 IP 抓取 | 200–600 元/月 | 机器 + 多 IP + 运维时间 | IP 池轮换 + 指纹隔离 |
| 代理转发业务 | 150–500 元/月 | 带宽为主 | 按流量单价倒推机型 |
还有一个常被忽略的杠杆是缓存。同一份资源反复抓取是纯浪费，加一层本地缓存通常能直接砍掉三成以上的请求量：
# 用本地磁盘做简单缓存，第二次访问直接命中
mkdir -p /var/cache/crawl
curl -s -A "Mozilla/5.0" "https://目标站点/页面" \
-o /var/cache/crawl/$(echo "https://目标站点/页面" | md5sum | cut -d' ' -f1).html
# 带 ETag / Last-Modified 的条件请求，只在内容变更时才拉全量
curl -s -o /dev/null -w "%{http_code} %{size_download}\n" \
-H 'If-None-Match: "etag_value"' "https://目标站点/页面"七、哪些事能做、哪些事不能做，合规边界必须说清楚
这一节是硬约束，不是免责声明。做爬虫和代理的人多数知道有边界在哪，但在赶进度的时候会选择性忽略，这恰恰是最大的风险来源。
延伸对照：hostwinds 的公开机型与线路说明，可结合本节的判断标准自行核对。
最基本的三条红线。第一，不得绕过访问控制。验证码、登录墙、付费墙、明确的 robots.txt 禁止路径，这些是站点所有者表达意图的方式，技术上能绕不等于可以绕。第二，不得规避已经生效的封禁。IP 被封之后换 IP 继续打，属于对抗性行为，风险成倍上升。第三，不得冒充他人身份获取数据，盗用账号、伪造身份信息都属于违法范畴。
合法且常见的用途是存在的，而且范围并不窄。搜索引擎的官方 API、自家产品的自动化测试、公开数据集的定期同步、已获授权的内容监测、学术研究中的公开数据采集、个人备份自己有权访问的内容。这些场景用正规的 VPS 加正规的 API 就能解决，不需要碰任何灰色手段。
关于 robots.txt 的态度需要说清楚一点：它是站点给自动化程序的声明，遵守它是行业惯例，也是法律上认定"合理访问"的重要参考之一。抓取前先读它，并在代码里真的去遵守，不要只是走个形式。
频率控制是最容易做到也最容易忽略的自律。合理速率的判断标准不是"我没被封就是合理的"，而是"我的请求量相对于该站点的正常访问量是否可忽略"。一个日访问十万的站点，你每小时抓两千次可能没问题；一个日访问五十的站点，你每小时抓两千次就构成了事实上的拒绝服务。
数据使用同样有边界。抓到的数据如果包含个人信息，要考虑删除权和存储期限；抓到的内容如果用于再分发，要考虑版权授权。把爬取来的数据直接拿去训练模型、或者做成商业产品，风险点跟技术难度完全不是一个量级。
从服务商角度看，多数正规 VPS 商家在条款里都会禁止代理转售和滥用行为，而被判定违规的后果通常是直接停机甚至封禁账号。所以选商家时也值得看看他们的条款，如果某家的产品页明确写着支持代理、不限制流量，这类商家要么在灰色地带经营，要么有其他风险点，同样需要评估。
八、踩坑复盘，五个真实翻车的环节
第一个坑是并发没设上限。写完爬虫顺手开了 50 个线程，结果目标站点立刻返回 429，接着自己的 IP 被标记，整台机器的 IP 段信誉都被拖累。正确做法是每个 IP 设 3 到 8 并发的硬上限，超了就排队而不是硬发。
延伸对照：justg 的公开机型与线路说明，可结合本节的判断标准自行核对。
第二个坑是只改 IP 不改特征。换了一个干净 IP，请求头还是那个库默认的 UA 和 Accept，结果一样被拦。IP 和指纹是两个独立的维度，必须一起处理。
第三个坑是重试逻辑放大了伤害。遇到 403 或者 429 的时候自动重试，看起来提高了成功率，实际效果是把限流信号放大十倍，直接触发永久封禁。正确做法是遇到 429 立刻退避，指数级加等待，遇到 403 则换身份。
第四个坑是缓存没做。同一个列表页反复全量抓，流量成本直接翻几倍，而且高频访问同几个 URL 本身就是异常特征。
第五个坑是把成本算成了月费。等到账单出来才发现流量费用是机器本身的两倍多，预算失控只能中途砍任务，而这时候沉没的开发成本已经花掉了。
还有一个不算坑但同样重要的细节是时间戳和时区。抓到的数据如果需要按时间排序，注意服务器时区与目标站点的时区差异，以及容器里 UTC 与本地时间混用导致的跨天判断错误。这类 bug 极难在测试中发现，却会让整份数据集的时间维度失真。
九、落地清单与配置建议
第一步是定位目标站点，评估规模。算出需要多少并发、每月多少流量、目标站点能承受的合理频率，这三个数字决定了后面所有的选型。
延伸对照：spinservers 的公开机型与线路说明，可结合本节的判断标准自行核对。
第二步是选机型。按并发和流量两个维度取交集：并发决定核数与内存，流量决定带宽与额度。中小规模抓取从 2 核 4G 起步通常够用，注意 vCPU 是共享资源，超卖普遍存在，核数买多不等于性能线性提升。
第三步是选线路。做爬虫和代理基本只关心两件事：到目标站点的连通性和延迟，选离目标站点近的机房通常优于选对国内优化线路。除非你的目标站点就在国内并且需要高质量访问，那又是另一回事。
第四步是 IP 策略。初期用单 IP 小规模跑通流程，把抓取成功率调到八成以上，再考虑引入 IP 池扩并发。反过来先堆 IP 的做法，通常是钱花了不少、问题一个没解决。
第五步是加防护与监控。至少要有的三个监控是：错误率、响应码分布、单个 IP 的请求频次。任一项越界就自动降速或换 IP，别靠人盯。
# 简单的频次自检脚本，超过阈值就退出当前任务
count=$(wc -l < /var/log/crawl_requests.log)
if [ "$count" -gt 5000 ]; then
echo "本小时请求数 $count 超过阈值 5000，主动退避"
sleep 600
fi第六步是设置备份与快照。抓取任务的中间结果可能很贵，机器出问题之后重建需要时间，快照能在几分钟内回到可用状态。
最后是成本控制。按前面那套折算方法算一遍每条有效数据的成本，再对照可接受的预算，超了就回去调有效率或者调缓存，不要用加机器来掩盖单问题。
十、常见问题
VPS 做代理和做爬虫，配置上最大的区别是什么？ 代理更吃带宽和 IP 信誉，因为流量全程中转；爬虫更吃 CPU、内存和并发控制能力，因为要解析和渲染。中小规模抓取从 2 核 4G 起步通常够用，代理则要优先看带宽端口宽度和流量额度。
数据中心 IP 和住宅 IP，选哪个？ 住宅 IP 在风控评分上占优，但不是普通 VPS 商家能稳定提供的，价格高、来源合规性参差。绝大多数个人开发者应当用数据中心 IP，然后把精力放在指纹隔离和频率控制上，而不是去找灰色渠道的住宅 IP。
一个 IP 能跑多少并发？ 没有固定答案，取决于目标站点的速率限制和你的请求特征。保守做法是每个 IP 设 3 到 8 并发的上限，用多个 IP 轮换来扩总量。真正的上限要自己压测，并观察 429 和验证码出现的位置。
被封了怎么办，怎么区分是 IP 问题还是代码问题？ 先换一台机器用完全相同的脚本跑一次，那台正常就是 IP 问题，两台都失败就不是 IP。响应体出现验证码关键词、状态码变成 429 或 403、以及响应长度明显变短，都是 IP 侧限流的信号。
用 curl 加个 User-Agent 够不够？ 不够。现代风控看的是整套浏览器环境的一致性，包括请求头组合、TLS 握手指纹、HTTP2 设置、Cookie 行为和交互轨迹。要么用 Playwright 这类真实浏览器上下文，要么用指纹伪装库并跟上检测版本。
成本应该怎么核算？ 折算到每条有效数据和每 GB 有效流量，而不是月费。有效率是整套账里最关键的变量，一个能自测的爬虫工具一个月能省下的流量和 IP 成本，通常远大于换机器省下的钱。
爬取速度是不是越快越好？ 不是。合理速率的判断标准是你的请求量相对于目标站点的正常访问量是否可忽略。抓取一个日访问量很小的站点时，高频请求已经构成事实上的服务干扰，风险不只是被封 IP。
robots.txt 到底要不要遵守？ 要。它是站点给自动化程序的明确声明，遵守它是行业惯例，也是法律上认定合理访问的重要参考。抓取前先读，并在代码里真正遵守，不要只做形式检查。
用 VPS 做代理转售有什么风险？ 多数正规商家的服务条款禁止代理转售与滥用，违规后果通常是停机或封号，且已付费用难以追回。另外在很多司法辖区，未经许可转售网络接入服务本身也可能触碰合规红线。
换到更贵的机器，能让抓取更稳吗？ 不一定。抓取失败的主因通常是 IP 信誉和指纹特征，而不是配置。配置只影响单机能承载的并发上限，先把有效率和指纹这两项做对，再考虑升级机型。
喜欢 
高兴
鬼脸
呵呵
无聊
伤心
