简介这是一份基于Python与Selenium的1688商品信息爬虫项目包含完整可运行代码面向高校计算机专业学生及电商数据分析人员可用于毕业设计、课程设计或商品数据采集实践。压缩包共19个文件约985KB涵盖7个Python脚本含核心爬虫模块、登录Cookie获取、京东/淘宝扩展采集、1份Word项目报告、3份Markdown说明文档以及JSON配置文件、环境依赖清单和示例图片等脚本按功能拆分便于单步调试文档涵盖需求分析、数据库设计及实现说明整体结构与注释清晰便于二次修改和迁移至其他电商平台。项目内置完整可运行的采集流程支持Selenium自动化操作浏览器处理登录、翻页与数据提取并附有技术报告和调试说明从环境搭建到运行测试均有覆盖。此外压缩包内还提供异常提示音频与页面截图便于定位采集过程中的中断情况这些细节对初学者尤为友好。目前已有80人学习下载适合需要以Python完成电商数据抓取课设、毕设或搭建早期原型的开发者。1. 1688 商品信息爬虫用 Selenium 自动化采集这事儿值不值得下场1688 商品信息抓取难的不是写代码而是决定用哪种方式去碰它。标题里的“1688商品信息爬虫Selenium自动化采集”方案核心逻辑是让 Chrome 替你去搜索、翻页、点开详情再把渲染后的页面文本抓下来。它解决的痛点很直接用 requests 请求同一个地址返回的 HTML 里可能连价格都是空的因为前端做了大量异步渲染Selenium 把这些步骤交给真实浏览器执行省去逆向接口签名和排雷的功夫。这个方案适合商品量在几千到几万的中小规模采集也适合做选品、比价、市场分析的人先把数据跑起来。它不为高并发设计一天几十万条不是它的活。全文按选型、落地、排错展开照着敲能出数据跑挂了也知道去哪改。2. 为什么 1688 商品采集要选 SeleniumRequests 和 Scrapy 输在哪2.1 动态渲染与签名接口静态请求为什么拿不到商品数据先说结论我在实际做电商数据抓取时优先尝试的一定是 requests 加解析。成本最低、速度最快不需要额外维护浏览器驱动。但在 1688 这里第一波尝试通常会被两个问题卡住。第一个问题是页面本身是动态渲染的。用 requests 直接 GET 搜索页拿到的 HTML 很多是模板骨架商品列表、价格、销量这些字段要等浏览器执行完 JavaScript 之后才会被填充到 DOM 节点里。即使你用 BeautifulSoup 去解析也找不到想要的数据。第二个问题是接口层的签名校验。1688 的很多数据都来自独立的异步接口接口请求里带着动态生成的签名参数和 cookie如果不分析前端打包后的 JS 代码很难凭空构造出合法请求。分析 JS 不是不可能但每次前端改版签名算法你都要重新逆向维护成本很高。所以 Selenium 的本质是放弃在 HTTP 层跟前端较劲转而在浏览器层模拟用户操作。浏览器自己执行 JS异步数据会自然渲染出来你只需要等元素出现然后提取文本。这种思路下requests 的缺点被绕开代价是慢、吃内存、需要一台能跑浏览器的机器。从我经手的项目看Selenium 适合几千到几万条的商品采集像是做选品、行情监控、市场调研每天抓一轮完全没问题。如果你要长期跑百万级数据Selenium 的吞吐量不够需要用接口逆向加分布式或者把抓取频率压到接近人工操作耗时又不可接受。这决定了这个标题的方案天花板先跑通再评估要不要换技术栈。这里我一般会把项目报告的开篇写成「为什么选型 Selenium」因为后面所有参数调优和踩坑记录都是基于这个决定。没有这个前提后来的脚本很容易被误改成半吊子的接口请求两边都守不住。方案动态渲染签名接口吞吐量维护成本Requests不支持需要逆向高高Scrapy不支持需要逆向高高Selenium支持无需逆向低中2.2 Selenium 到底解决哪一层问题别指望它免疫反爬很多人以为用了 Selenium 就不会被反爬这个认知有点危险。Selenium 帮你解决的是「渲染」这层问题不是「反爬」这层。真实浏览器确实比 requests 更像人但它还是有明显的自动化指纹比如window.navigator.webdriver属性只要对方前端写了一段检查代码Selenium 还是会被识别出来。所以在做采集方案时我一般会把 Selenium 和风控应对组合起来用一是尽量保持浏览器外观和正常用户一致不随便加headless因为无头浏览器很容易被识别二是手动维护登录态通过 Cookie 方式让会话更稳定三是抓取频率必须压到接近人工配合随机延时避免因为访问间隔太短触发限流四是做好验证码出现的预期不指望代码能自动绕过而是让它停下来等人处理。这一整套下来Selenium 才能在一个相对稳定的状态下持续产出。标题里说它是「自动化采集」容易让人以为启动就全自动了实际上自动化只是把重复操作自动化遇到风控时仍然需要介入。把这一点想清楚后面调优时你才不会觉得是玄学。2.3 环境准备Python、Chrome、WebDriver 版本的匹配方式开始写代码之前先把环境理顺。Selenium 通过 WebDriver 控制浏览器浏览器和驱动之间必须版本对应否则会在启动时直接报SessionNotCreatedException。这是我的老项目里踩坑最多的一步很多同学卡在这一步就放弃了。# 创建虚拟环境避免污染系统 Python python -m venv .venv # 进入虚拟环境Windows 命令是 .venv\Scripts\activate source .venv/bin/activate # 安装 Selenium 客户端库 pip install -U selenium # 可选自动下载匹配的驱动 pip install -U webdriver-manager这段命令做的事情是创建独立的 Python 环境然后安装 Selenium 库。-U表示升级到最新版本如果之前有旧版本可以顺带刷新。webdriver-manager会自动找到本地 Chrome 的版本并下载对应驱动省掉手动检查版本的步骤。如果所在网络环境不允许它自动下载也可以去浏览器驱动管理中心手动下载放到 PATH 里。装完依赖后建议先跑一个最小验证脚本确认环境和驱动没问题再继续from selenium import webdriver driver webdriver.Chrome() driver.get(https://www.1688.com/) print(driver.title) driver.quit()这段代码启动一个 Chrome 实例打开 1688 首页然后打印标题。能打印出「1688」相关文本说明 WebDriver 连接成功。如果这里就报错优先检查三样东西Chrome 版本、驱动版本、PATH 路径。使用webdriver-manager的话webdriver.Chrome()需要改成Service方式加载自动管理的驱动代码略有不同但原理一致。环境准备好了下一个问题才是真正进入采集逻辑。我见过太多项目在环境配置阶段翻车最后以为是代码问题其实是驱动没配对。这一节的结论可以写进项目报告作为部署前置条件。3. 从零跑通一个 1688 商品信息采集脚本搜索到详情一条龙3.1 初始化 WebDriverOptions 的关键参数不能上来就 headless写一个可用的采集脚本第一步是把浏览器启动参数配置好。很多人为了省资源一开始就加headless结果在 1688 上成功率很低。我的习惯是先用有头模式把整个流程调通确认元素定位没问题后再决定要不要切无头。以下是一个初始化 WebDriver 的常见写法from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() options.add_argument(--start-maximized) # 窗口最大化便于调试时观察 options.add_argument(--disable-gpu) # 禁用 GPU减少资源占用 options.add_argument(--langzh-CN) # 浏览器语言设为中文 # 如果确实需要无头可以加下面这行但风控识别率会上升 # options.add_argument(--headlessnew) driver webdriver.Chrome(optionsoptions) driver.implicitly_wait(5)这些参数里--start-maximized是让窗口最大化保证页面按桌面端布局渲染--disable-gpu在服务器没有显卡时避免 GPU 进程报错--langzh-CN让页面返回中文内容解析时不容易出现语言不一致。implicitly_wait(5)是全局隐式等待元素查找失败时最多等 5 秒。它是兜底策略后面我会用显式等待替代大部分场景。注意不要在初始化阶段加入driver.execute_cdp_cmd之类的指纹清理先让脚本跑起来再说。如果一开始就叠加太多东西出了问题你分不清是定位失败还是指纹被识别。3.2 搜索关键词并采集列表页商品链接搜索页是采集的入口。打开 1688 首页后找到搜索框输入关键词触发搜索。因为页面结构会改版下面代码里的选择器只是一个示例实际使用时需要用 F12 检查到当前页面对应的元素再替换进去。这也是爬虫脚本的一个常见特点90% 的维护工作都在核对选择器。from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC # 打开首页并等待搜索框出现 driver.get(https://www.1688.com/) search_box WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CSS_SELECTOR, input[typesearch])) ) search_box.send_keys(保温杯) search_box.submit() # 等待商品列表渲染完成 WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CSS_SELECTOR, div.offer-list-item)) ) # 提取当前页所有商品卡片的链接 links [] for item in driver.find_elements(By.CSS_SELECTOR, div.offer-list-item a): href item.get_attribute(href) if href: links.append(href) print(f本页拿到 {len(links)} 个链接)WebDriverWait的作用是轮询等待某个条件成立超时则抛异常。这里等搜索框和商品列表比time.sleep(3)更准确页面快就早执行页面慢就多等。submit()触发搜索框所在表单的提交比手动点击搜索按钮少一次定位。列表页的offer-list-item是模拟类名实际以页面 DOM 为准你也可以用div[class*offer]这种模糊匹配能减少类名改版带来的影响。拿到链接后我一般会把当页链接先存进一个待处理队列然后处理翻页。1688 的列表页可能是点击翻页也可能是滚动加载。如果是滚动加载就用下面的 JavaScript 循环滚动到底部for _ in range(5): driver.execute_script(window.scrollTo(0, document.body.scrollHeight)) time.sleep(random.uniform(1, 2)) # 滚动后再统计一次卡片数量判断是否还有新内容 card_count len(driver.find_elements(By.CSS_SELECTOR, div.offer-list-item))这段循环是模拟鼠标滚轮向下滑动每次滚到底部触发懒加载等 1-2 秒让新内容渲染出来。滚动次数要结合页面实际数据量调整如果滚了五轮数量还在涨说明还有很多商品可以设一个更长的循环直到数量不再变化。这里的random.uniform(1, 2)是随机延时避免两种极端情况太快触发反爬太慢拖长采集时间。3.3 进入详情页解析商品名、价格、销量与 SKU列表页只能拿到概括信息要拿到准确的商品名、价格区间和销量一般需要进入详情页。详情页的 DOM 结构更稳定但也更复杂。我常用的策略是抓到一个链接就开一个详情页解析完关闭回到列表页继续下一个。注意详情页打开后很多字段是延迟渲染的所以必须用显式等待。def parse_detail(driver, url): driver.get(url) name WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CSS_SELECTOR, h1)) ).text price try: price_el driver.find_element( By.CSS_SELECTOR, span[class*price], span[class*Price], div[class*sale-price] p ) price price_el.text except Exception: price sales try: sales_el driver.find_element( By.CSS_SELECTOR, span[class*sale-count], span[class*sales], div[class*order] span ) sales sales_el.text except Exception: sales return { name: name.strip(), price: price.replace(\n, -), sales: sales.replace(笔, ).strip(), url: url, }这段函数做了三件事等详情页主标题出现确保页面加载进入正常状态分别用带备选的选择器找价格和销量最后把结果整理成字典。这里用try/except包裹每个字段是因为详情页存在多种商品模板有的商品没有销量有的商品价格只显示「面议」直接查找会抛异常。replace(\n, -)是把价格区间里的换行符统一成-方便后续入库。需要特别说的是这里的选择器要结合实际情况调整。1688 改版很频繁同一个字段在不同类目下可能用不同的 class 名。写死一个选择器是采集脚本最常见的死法所以我习惯在核心字段上给多个候选选择器让代码能自动兼容。3.4 数据清洗与 CSV 输出兼容 Excel 打开乱码解析完详情页下一步是把数据落盘。采集脚本的输出格式我一般首选 CSV因为轻量、通用Excel 可以直接打开后续也方便转到数据库。但写 CSV 时要注意两个细节编码和空行。import csv from datetime import datetime def save_to_csv(records, path): with open(path, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([商品名, 价格, 销量, 链接, 抓取时间]) for r in records: writer.writerow([ r[name], r[price], r[sales], r[url], datetime.now().strftime(%Y-%m-%d %H:%M:%S), ])newline是 Python 官方文档推荐写法避免在 Windows 上每行之间出现空行。encodingutf-8-sig会在文件头部写入 BOM这样 Excel 打开 CSV 不会乱码如果用utf-8写入记事本正常但 Excel 会显示乱码。字段顺序按「商品名、价格、销量、链接、抓取时间」排好方便后续查看。到这里一个最小可用的 1688 商品信息爬虫已经成型搜索、翻页、进详情、落 CSV。接下来要解决的是让这个脚本能稳定长期跑的问题也就是下一章的内容。4. 让脚本更耐用的四个实战处理等待、登录态、异常与限速4.1 自定义显式等待避免time.sleep堆成习惯采集脚本写久了会本能地在每个操作之间塞time.sleep(3)。如果页面在 3 秒内加载完脚本就白等如果超过 3 秒脚本就报错。我自己早期吃过这个亏后来把等待逻辑抽成了工具函数每个页面的关键节点都用显式等待。from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By def wait_for(driver, selector, timeout10): return WebDriverWait(driver, timeout).until( EC.presence_of_element_located((By.CSS_SELECTOR, selector)) ) # 用法示例 search_box wait_for(driver, input[typesearch], timeout15)这个函数把WebDriverWait的使用封装成一行调用。presence_of_element_located只检查元素是否存在不检查是否可见如果需要交互改用element_to_be_clickable。参数timeout是超时秒数建议给搜索框 15 秒详情页主标题 10 秒列表容器 12 秒。超时后要记录日志而不是让异常直接崩溃。显式等待和隐式等待同时用时有时会叠加等待时间造成不必要的延迟。我的做法是只保留显式等待把初始化里的implicitly_wait设置为 0 或干脆去掉。这样每次查找失败时能立刻进入自定义等待逻辑调试时也更容易定位问题。4.2 Cookie 登录态的保存与注入1688 的部分数据需要登录才能看全特别是价格和联系方式。Selenium 脚本每次启动都重新登录很麻烦所以我会做一个「手动登录一次Cookie 存到本地下次直接注入」的机制。这样既不用每次扫码也能维持一个相对真实用户的会话。import pickle # 第一次运行手动登录并保存 cookie driver.get(https://login.1688.com/) input(请在浏览器里完成登录按回车继续...) with open(1688_cookies.pkl, wb) as f: pickle.dump(driver.get_cookies(), f) # 后续运行注入 cookie driver.get(https://www.1688.com/) cookies pickle.load(open(1688_cookies.pkl, rb)) for cookie in cookies: driver.add_cookie(cookie) driver.refresh()这里有个容易踩坑的顺序问题必须先访问一次目标域名让浏览器持有该域名的会话上下文再使用add_cookie否则 Cookie 会被拒绝。保存时用pickle序列化成二进制文件读取时注意文件路径。Cookie 会过期所以脚本里要检测到登录失效时重新走一遍登录流程。检测登录失效的简单方法是注入 Cookie 后访问一个需要登录才能看到的页面比如「我的报价单」如果页面跳转到登录页说明 Cookie 已失效。这时可以暂停脚本让用户重新扫码登录并更新1688_cookies.pkl再继续执行。4.3 异常捕获与重试机制别让单条数据拖垮整个任务采集过程中页面加载超时、元素不存在、网络波动都很常见。如果你不加保护一个异常就会让脚本退出前面的几百条数据白抓。我的做法是把单条商品的解析放到一个带重试的函数里重试超过设定次数就记录失败链接继续下一个。from selenium.common.exceptions import TimeoutException, WebDriverException MAX_RETRY 3 def fetch_with_retry(driver, url): for attempt in range(MAX_RETRY): try: return parse_detail(driver, url) except (TimeoutException, WebDriverException) as exc: print(f第 {attempt 1} 次失败: {url}, 错误: {exc}) driver.back() return None这里的MAX_RETRY是单条链接的最大重试次数我一般设为 3 次。注意每次失败后不要直接driver.get下一个链接可以先driver.back()回到列表页让页面状态恢复。这样设计可以避免浏览器处于错误页面时继续加载新网址导致后续全部超时。失败的链接还可以写入一个failed.txt最后统一补抓。补抓逻辑不复杂读取failed.txt里的 URL重新调用fetch_with_retry成功则从文件里删除这一行。如果你全程用同一个浏览器实例跑很久建议每抓满 500 条就重启一次浏览器清空内存中的页面缓存这个操作能有效降低后续请求的失败率。4.4 随机限速与频率控制别把自己跑成高并发攻击Selenium 脚本天生比 requests 慢但如果你在循环里不做任何限制它照样可以每两三秒请求一次页面。这个频率在 1688 的风控眼里已经异常了跑几百条就会碰到验证码。所以要主动在循环里加随机延时。import random, time def random_pause(min_sec3, max_sec6): time.sleep(random.uniform(min_sec, max_sec)) # 每次循环调一次 random_pause(3, 6)random.uniform(3, 6)生成 3 到 6 秒之间的随机浮点数让请求间隔不是固定的。固定间隔其实更容易被识别因为真人操作不可能每次都卡得那么准。运行时可以根据实际情况调整区间采集密度低就 5-8 秒密度高就 2-4 秒。如果遇到验证码我通常会额外等待更长时间再人工处理而不是直接加速。延时本身也是成本。如果商品链接很多可以考虑用并发浏览器窗口来提速但每个窗口都要分配独立 IP否则所有请求还是同一个出口限流风险反而更大。Selenium 方案尽量不要追求并发把单窗口的稳定性做好数据产出就已经足够满足大多数需求。5. 避坑指南一线采集最常见的 5 个雷区这一章的内容来自我实际跑采集脚本时反复遇到的翻车现场。每条都经历过从诡异到恍然大悟的过程写在这里帮你省掉几小时排查。采集脚本很多问题不是代码写错而是页面结构、编码规范和风控机制在捣乱。5.1 元素定位时好时坏别在一个选择器上吊死现象同样的脚本上午能批量抓下午开始报NoSuchElementException卡在第一个字段。原因1688 页面经常做 A/B 测试或类目差异化渲染商品卡片在不同条件下使用不同 class 名。写死的选择器一旦碰上某批商品结构不同就找不到元素。解决核心字段用多候选选择器比如span[class*price], span[class*Price]每个字段用try/except隔离避免一个字段失败导致整条数据丢失。另外脚本启动时可以先打印页面标题和 URL确认进入的是预期页面。还有个经验值得分享浏览器 DevTools 里能一键复制 selector但复制出来的很长改版就断。我会在复制出的 selector 基础上手动缩短只保留带业务语义的 class 属性比如div[class*offer-list-item]。这样能兼顾稳定性和可读性。5.2 价格字段拿到的是区间价不是最终价现象列表页抓到的价格是「12.00-30.00」入库后没法直接参与价格分析。原因1688 商品往往有多个 SKU列表页为了展示方便只显示价格区间。单 SKU 商品才会显示单一价格。解决从列表页拿到的价格只做参考最终价格以详情页为准。如果详情页仍然返回区间价就在数据表里把价格拆成price_min和price_max两个字段避免后续分析时把字符串当数字解析出错。价格解析是数据清洗的重灾区。常见的情况是带货币符号、含「起」字、或者多个价格用换行分隔。我一般在解析后做一层标准化去掉「¥」「起」、把换行替换成-、空值保留为空字符串。这层标准化逻辑放在parse_detail函数末尾避免输出阶段再重复处理。5.3 无限滚动页面漏采翻页逻辑不生效现象列表页没有「下一页」按钮只有滚动加载脚本只抓到前 20 个商品就停了。原因页面采用懒加载只有浏览器滚动到底部时才会发起异步请求加载新商品。静态解析无法触发这个动作。解决用driver.execute_script(window.scrollTo(0, document.body.scrollHeight))循环滚动每滚一次等 1-2 秒统计卡片数量直到不再增加。也可以直接定位「加载更多」按钮并点击这两种方式看页面实际交互。判断滚动是否结束我一般用一条简单规则连续三次滚动后商品卡片数量都没有变化就认为到底了。这个规则能避免固定轮次数导致多等或少抓。实现时可以把每轮的商品卡片数量放进列表比较末尾三个值是否相等。def scroll_until_end(driver, item_selector, max_scrolls20): previous_count 0 stable_rounds 0 for _ in range(max_scrolls): driver.execute_script(window.scrollTo(0, document.body.scrollHeight)) time.sleep(random.uniform(1, 2)) current_count len(driver.find_elements(By.CSS_SELECTOR, item_selector)) if current_count previous_count: stable_rounds 1 if stable_rounds 3: break else: stable_rounds 0 previous_count current_count这个函数把滚动、延时、结束判断封装在一起实际用的时候传入商品卡片选择器就行。max_scrolls20是保护性上限防止某些页面无限加载导致死循环。5.4 登录态恢复失败Cookie 注入顺序不对现象保存 Cookie 后重新启动脚本明明导入了 Cookie刷新页面后还是回到登录态。原因add_cookie必须在浏览器已经打开目标域名页面的前提下调用。如果driver.get()还没访问 1688直接加 Cookie 会被拒绝。解决正确顺序是先driver.get(https://www.1688.com/)再遍历add_cookie最后driver.refresh()。如果仍然失效检查 Cookie 里的 domain 字段是否是 1688 相关域名以及是否过期。另外要注意 Cookie 的持久化文件不要放在游戏目录以外的共享目录避免多任务同时读写导致文件损坏。我一般会为每个采集任务单独建一个文件夹Cookie 文件和数据输出都放在里面这样出问题时日志、失败列表、结果文件都在一处排查效率高很多。5.5 CSV 文件用 Excel 打开乱码显示一团问号现象脚本在终端输出数据正常用 Excel 打开生成的 CSV 文件却是乱码。原因CSV 写入时用了默认或 UTF-8 编码Excel 在 Windows 下默认按本地编码解析导致中文字符显示异常。解决写入文件时指定encodingutf-8-sig这个编码会在文件开头写入 BOM 标记Excel 能正确识别为 UTF-8。如果已经生成了乱码文件可以先用文本编辑器转码另存也可以重新跑一遍脚本。判断是不是编码问题有个快速方法先用记事本打开 CSV如果能正常显示中文再用 Excel 打开就乱码那八成是 BOM 缺失。改成utf-8-sig后重新生成问题基本消失。这个问题虽然小但会影响后续数据共享值得写进项目报告的「已知问题」一节。6. 进阶用法与数据质量验证把采集脚本变成可靠的数据管道跑通采集脚本后接下来要解决的是「数据可靠不可靠」和「每次怎么跑」。这两个问题决定这个爬虫能不能作为稳定工具长期用而不是一次性脚本。我一般会从数据校验和增量采集两个方向去补强。数据校验先做字段级别检查。写一个简单的校验函数不合格的记录不进主数据表def validate_record(rec): if not rec.get(name) or len(rec[name]) 2: return False if not rec.get(price): return False if not rec.get(url, ).startswith(http): return False return True这个函数检查三个基本点商品名不能为空且至少有 2 个字价格不能缺失链接必须是完整 URL。校验不通过时我会把原始记录单独写到bad_records.csv方便回头人工核对。这样主数据表保持干净下游做分析时不会因为脏数据中断。增量采集的核心是去重。如果每次跑全量数据量大了以后脚本会越来越慢而且会产生大量重复记录。我建议用一个seen_hashes.txt保存已经抓过的商品链接哈希import hashlib seen set() with open(seen_hashes.txt, r) as f: seen {line.strip() for line in f} for url in pending_links: h hashlib.md5(url.encode(utf-8)).hexdigest() if h in seen: continue # 采集并写库 seen.add(h)用哈希判重的好处是内存占用小而且不用保存完整 URL。如果你需要把数据归档到更大范围可以在采集完成后用pandas.read_csv读取 CSV再写入 SQLite 或数据库方便后续做价格趋势和商品分布分析。这个方案不需要引入重量级框架一个纯 Python 脚本就能撑起日常电商数据抓取需求。我自己最早用这套方案时为了赶数据量把延时调得很短结果一小时内就被限流。后来把延时拉长、加失败队列虽然慢了一倍但每天能稳定产出再也不用半夜起床处理验证码。先求稳再求快这是我在电商数据抓取这件事上最大的教训。希望帮到你。本文还有配套的精品资源点击获取