简介面向阿里云专有云企业版V3.12.0 DataWorks使用者的用户指南PDF适合大数据开发、数据治理、数据服务及运维人员系统查阅平台功能与操作规范。内容按登录控制台、创建工作空间、快速入门、数据集成、数据开发、数据治理、数据服务、数据安全等章节展开并交代法律声明、通用约定、警示级别和命令行、参数排版规则便于读者理解专有云环境下的任务编排、权限配置、质量监控与安全管控流程。其中快速入门覆盖建表上传、业务流程、同步任务、周期依赖与运行排错数据开发支持SQL与Python脚本并配图形化编排数据治理侧重资产、元数据与质量检查数据服务可发布数据API。资源包共1个PDF文件约32.03MB单册结构完整目录层级清晰可按章节检索或通读。已有187人学习可作为搭建工作空间、梳理ETL流程、核对功能入口和排查配置问题的案头参考。1. 一份 900 页的 PDF先读目录比读正文值钱接手一套内网离线集群的时候最怕的不是没有文档而是文档太厚。这份《专有云企业版 V3.12.0 DataWorks 用户指南》20200706 版本PDF 从登录控制台一直排到数据安全光目录就占了好几页。第一次翻开的人往往从第 1 页顺着往下读读到“数据集成”那章已经过去两个小时回到控制台还是不知道该点哪里。它本质上是专有云环境下 DataWorks 的完整操作手册登录、工作空间、快速入门、数据集成、数据开发、数据治理、数据服务、数据安全外加法律声明和一套通用约定。适合两类人——一类是刚被派去搭内网数据平台的开发需要照着步骤把一条离线链路跑通另一类是要给团队定规范的人需要从 Reader/Writer 插件矩阵、调度参数、资源组这些细节里抠出边界条件。我的读法是反的先看目录里“数据集成”和“数据开发”两章的层级把支持的数据源清单和节点类型抄下来再回头翻快速入门。这样你读快速入门时脑子里已经知道后面有哪些东西可选不会把一个临时方案当成唯一方案。2. 从登录到第一个工作空间三个必配项与六步入门这一章讲的是从零到“任务能跑起来”这一段。文档里这几节加起来不到二十页但现场卡住人的地方几乎全在这里控制台地址从哪来、账号该给什么权限、工作空间绑哪个计算引擎、资源组选共享还是独享。把这几件事定下来后面数据集成和数据开发才有地方落。2.1 先认环境再认按钮专有云和公有云文档的差异专有云部署在客户自己的机房控制台域名、Region、可用区、账号体系全部由现场运维定义文档里的截图只保证界面元素一致不保证入口地址一致。常见的差异有三处登录地址是内网域名或 IP 加端口不是某个固定网址账号走的是现场的统一身份体系可能是主账号开子账号也可能对接了内部的认证系统部分依赖公网的能力在专有云里直接裁剪掉了数据源配置页面上压根没有对应选项。所以在翻正文之前先把文档最前面那几页“通用约定”看完。它把提示分成了四级这四级在后面的操作里是真会救命的约定级别含义典型出现位置禁止操作会导致系统重大变更甚至故障、数据丢失重置、删除工作空间、清空表警告会导致业务中断且恢复需要时间重启、切换资源组、修改调度周期注意用户必须了解的补充信息参数取值范围、默认值、权限前置条件说明最佳实践和窍门不是必须遵守批量操作技巧、界面快捷方式现场血泪经验是只看正文的步骤不看这四级标记很容易在“删除工作空间”那一步把整个项目的调度任务一起端掉。文档里凡是标了“禁止”的地方我都会在变更单上单独拉一行让人复核。2.2 登录控制台地址、账号、权限三件事登录这一步本身没什么技术含量卡人的永远是前置条件。地址问运维要账号问主账号要权限问工作空间管理员要三样缺一样都进不去。拿到地址之后先做一次连通性确认别在浏览器里反复刷“无法访问”# 1. 确认域名解析到的是内网地址排除本地 DNS 走了外部解析 dig short dataworks.console.现场内网域名 # 2. 确认端口可达-k 用于自签证书场景-m 5 限制 5 秒超时 curl -k -I -m 5 https://dataworks.console.现场内网域名/ # 3. 如果第 2 步超时从同网段的跳板机再试一次区分是网络策略还是本机问题dig那一步是为了区分“解析错了”和“网络不通”这两个问题的处理人完全不同。curl -k里的-k是跳过证书校验专有云内部经常用自签证书不加这个参数会直接报证书错误很容易被误判成服务没起来。-m 5是超时内网正常情况下 1 秒内就有响应5 秒还没回基本可以判定被防火墙拦了。进到控制台之后第一件事不是急着建东西而是看右上角的工作空间列表是不是空的。如果列表里已经有别人建的空间说明这套环境不是全新的你后面建的资源可能和已有项目抢资源组这种情况要先跟管理员确认资源配额。2.3 创建工作空间计算引擎、资源组、环境模式工作空间是 DataWorks 里的项目单元它把计算引擎、成员、资源组、调度环境绑在一起。文档里这一节的参数不少但真正需要你拍板的是下面四项配置项作用现场建议计算引擎绑定决定 SQL 在哪跑通常绑 MaxCompute 项目也可绑 EMR 集群一个工作空间绑一个引擎项目别混绑混绑后表名解析会很乱调度资源组决定周期任务在哪台机器上被调度起来生产空间必须独享共享资源组在任务高峰期会排队数据集成资源组决定同步任务从哪台机器发起连接跨网段同步必须独享且要提前把资源组网段加进目标库白名单环境模式简单模式只有一个环境标准模式分开发和生产只要涉及上线流程就选标准模式代价是多一次发布动作“简单模式”和“标准模式”这个选择事后改起来非常麻烦。简单模式下开发和生产的任务在同一个空间里改完保存就生效适合做验证和小规模自用标准模式下开发环境的任务必须发布到生产才会进入周期调度多了一道手续但换来了“改坏了不影响线上”这个后悔药。我一般建议只要这套集群将来要接业务报表一开始就选标准模式别图省事。工作空间建完还有两件小事容易漏。一是加成员DataWorks 的权限是按空间授予的运维给你开了账号不等于你有这个空间的开发权限二是确认绑定引擎项目里的表已经初始化有些现场是引擎侧先建项目后接 DataWorks两边元数据没同步时会看到空表列表。2.4 快速入门的六步顺序不能乱文档第 3 章的快速入门把链路拆成六步入门概述、建表并上传数据、创建业务流程、创建同步任务、设置周期和依赖、运行及排错。这个顺序是有依赖关系的跳过任何一步都会在后面卡住。第一步建表直接在引擎侧执行 DDL 更稳-- 明细表按日期分区dt 放最后是 MaxCompute 的硬性要求 CREATE TABLE IF NOT EXISTS ods_user_action ( user_id STRING COMMENT 用户标识, action STRING COMMENT 行为类型如 click/view/pay, ts BIGINT COMMENT 事件时间戳毫秒 ) COMMENT 用户行为明细表 PARTITIONED BY (dt STRING COMMENT 日期分区格式 yyyyMMdd);分区字段必须写在最后写在中间会直接报错。dt用 STRING 而不是 DATE是因为调度参数传进来的就是yyyyMMdd的字符串用 STRING 免掉一次隐式转换也方便手工补数据时直接指定分区值。ts用 BIGINT 存毫秒时间戳不要用 TIMESTAMP跨时区导入时 TIMESTAMP 的解析规则经常和上游系统对不上。第二步上传数据小数据量用客户端的 tunnel 命令就够大数据量走数据集成。第三步创建业务流程注意业务流程本身不是文件夹它是调度的容器节点之间的依赖关系只在同一个业务流程内自动推导。第四步创建同步任务、第五步设置周期和依赖这两步合起来决定任务什么时候跑、跑完之后下游能不能动。最后一步“运行及排错”要看的是运行日志里的三段时间排队时间、启动时间、执行时间。排队时间长说明资源组不够启动时间长说明调度服务压力大执行时间长才是 SQL 或同步本身的问题。这个区分方法在文档里没有明说但排查时非常好用。3. 数据集成落地向导模式与脚本模式的切换点在哪数据集成是这份文档里篇幅最大的一块光数据源配置就列了三十来种Reader 插件二十多个Writer 插件二十多个。绝大多数人用不到十分之一但用到的那个如果配错了排查成本极高。这一章按“选哪个数据源 → 怎么测通 → 用哪种模式配 → 参数怎么调”的顺序走一遍。3.1 数据源清单先确认你要的那一个在不在文档 4.4.1 节列了支持的数据源全集大致可以分成五类类别代表数据源现场常见用途关系型数据库MySQL、SQL Server、PostgreSQL、Oracle、DB2、DM、DRDS、POLARDB业务库到数仓的每日抽数大数据存储MaxCompute、Hive、HBase、Hologres、Vertica、GBase8a、Lightning数仓内部层间流转、异构引擎迁移消息与日志DataHub、LogHub实时流式数据落离线文件与对象存储OSS、HDFS、FTP文件批量导入导出、日志归档NoSQL 与检索MongoDB、Memcache、Redis、OTS、Elasticsearch维表同步、结果回写、检索加速专有云环境里最容易翻车的是第一类和第五类关系型库的版本可能比文档写的低驱动不匹配NoSQL 的连接串里可能需要写内网域名而不是 IP。文档 4.4.2 节专门讲了数据源隔离意思是同一个逻辑数据源在开发环境和生产环境可以配成两条独立记录任务发布时自动替换。这个机制不用白不用标准模式下强烈建议开。3.2 连通性测试通过不等于任务能跑这是现场最高频的误判。文档 4.3 节的“数据源测试连通性”按钮发起方是你的浏览器所在的那台机器所在的网络位置而真正跑同步任务的是数据集成资源组所在的机器。两者网络路径不同测试通过只说明控制台到数据库通不说明资源组到数据库通。判断方法很直接看测试是通过控制台代理发起的还是资源组发起的。如果现场版本是控制台代理那测试结果的参考价值有限必须用一个真实的小任务验证。验证任务的配置尽量简单单表、单字段、where条件加个limit 1跑通再加字段。连接失败的排查顺序我固定成四步先看目标库的白名单里有没有资源组网段这一步占七成问题再看账号密码里有没有特殊字符导致转义错误然后看端口是不是被安全组挡了最后才怀疑驱动版本。顺序反过来做会在驱动上浪费半天。3.3 向导模式和脚本模式的取舍文档 4.5.1 和 4.5.2 分别讲向导模式和脚本模式。两者的关系不是新旧替代而是覆盖不同场景维度向导模式脚本模式字段映射界面点选支持同名映射JSON 手写支持常量、函数、动态列切分键界面上可填可填且能对每个 reader 单独设通道并发只能设总数可按通道细分配合内存参数脏数据容忍有阈值配置有errorLimit粒度高动态表名不支持支持配合调度参数拼分区学习成本低五分钟上手需要记住 JSON 结构判断标准很简单字段一一对应、目标表结构固定、不需要按分区动态写走向导模式涉及动态分区、需要控制单通道内存、需要容忍部分脏数据继续跑切脚本模式。我一般的习惯是先用向导模式点一遍生成基础配置再切到脚本模式改细节省得从零手写 JSON。文档里没写这个技巧但界面上的“切换脚本模式”按钮会带着已有配置过去。3.4 一份脚本模式同步配置逐段拆开下面这份配置是从 MySQL 抽数写到 MaxCompute 分区表包含了实际项目里最常用的几个参数{ type: job, version: 1.0, configuration: { setting: { speed: { concurrent: 4, throttle: false }, errorLimit: { record: 1000, percentage: 0.02 } }, steps: [ { stepType: mysql, name: Reader, parameter: { username: etl_ro, password: ******, connection: [ { jdbcUrl: [jdbc:mysql://10.x.x.x:3306/biz_db], table: [user_action], querySql: select user_id, action, unix_timestamp(create_time)*1000 as ts from user_action where dt ${bizdate} } ], splitPk: user_id, fetchSize: 1024 } }, { stepType: odps, name: Writer, parameter: { accessId: ${odps.accessId}, accessKey: ${odps.accessKey}, project: dw_project, table: ods_user_action, partition: dt${bizdate}, truncate: true, column: [user_id, action, ts] } } ] } }concurrent是并发通道数不是越大越好超过目标库的连接数上限会被拒绝一般从 4 起观察源库负载再往上加。errorLimit里的record是允许的脏数据条数percentage是占比阈值两个条件是“或”关系任意一个先到就停任务设得太宽会让错误静默吞掉设成 0 又会让一条脏数据打断整批。splitPk必须是数值型或有索引的整型字段用字符串主键切分会退化成单通道这个坑文档里写了但很容易忽略。querySql和table在同一个 connection 里二选一写了querySql之后column配置会失效。partition里拼的${bizdate}是调度参数手工运行的时候要自己给值不给会直接报错。Writer 侧truncate: true表示写入前清空目标分区。这个参数在补数据场景下是双刃剑重跑同一天会把之前的结果覆盖掉但如果那天有多个任务写同一个分区后跑的会把先跑的冲掉。我一般只在确定该分区独占的场景下开否则改成先删分区再插入的显式步骤。3.5 整库迁移的边界文档 4.6 节讲整库迁移目前覆盖 MySQL 和 Oracle 两类源。它的价值在于自动建表加自动配同步任务适合新系统上线时的一次性搬数。但它有三个明确的边界DDL 只能转换常见类型源库里的自定义类型、存储过程、触发器不会跟过来自增主键在目标侧的行为和源侧不同需要人工确认表名大小写在源库和目标库不一致时会建出两套表。我的做法是把整库迁移当成“生成初稿”的工具跑完之后一定要对一遍表清单和字段类型尤其是 DECIMAL 的精度和 VARCHAR 的长度这两项转换错误在后续计算里会变成数据失真不会报错最难查。4. 数据开发与调度节点类型选型与调度参数的坑建完工作空间、打通同步链路之后日常打交道最多的就是数据开发这一块。文档第 5 章从解决方案、SQL 编码规范一路讲到节点类型内容很杂我按“业务流程怎么组织 → 节点用哪种 → 依赖怎么设 → 三个面板怎么用”重新排一遍。4.1 业务流程是调度的容器不是文件夹很多人第一反应是把业务流程当目录用按业务线建一堆空流程节点到处放。这么做的后果是依赖关系断链节点之间的自动依赖只在同一个业务流程内推导跨流程的依赖必须手工挂挂漏了就会出现下游先跑、上游后跑。合理的组织方式是按“一条完整的数据链路”建流程贴源层同步 → 明细层加工 → 汇总层加工 → 导出/回写四段放在同一个流程里。流程数量控制在十几个量级超过这个数说明粒度切太细了。节点组是流程内的复用单元把一组固定的节点打包在多个流程里引用改一处生效多处适合那种每个业务线都要跑一遍的通用清洗逻辑。4.2 节点类型怎么选一张对照表文档 5.5 节列了十几种节点类型实际项目里高频的就下面几种节点类型适用场景注意事项数据集成节点跨库、跨存储的数据搬运与离线同步任务共用资源组注意并发上限ODPS SQL 节点数仓内的 SQL 加工占比最高单节点别写太长超过两百行拆成中间表ODPS Script 节点需要多语句顺序执行、带变量控制脚本内不能写 DDL 之外的复杂事务逻辑PyODPS 节点需要 Python 做数据处理或调引擎 API依赖第三方包要先确认集群里装了ODPS Spark 节点数据量大、SQL 表达不了的场景资源申请要单独报默认配额往往不够SQL 组件节点多段 SQL 复用参数要显式声明隐式依赖外部表容易漏选型上有个反直觉的点很多人以为 PyODPS 比 SQL 灵活所以优先用 Python实际在数仓加工场景里能写成 SQL 的一律写 SQL。原因是 SQL 节点的执行计划由引擎优化Python 拿到的是全量数据在客户端侧算数据量一大就 OOM。PyODPS 更适合做“调度引擎的胶水”比如跑完之后调接口发通知、动态生成分区。4.3 调度参数${bdp.system.bizdate}到底取的是哪天这是调度里最容易理解错的一个点。业务日期bizdate不是任务实际运行的日期而是任务所处理数据的日期。一个每天凌晨两点跑的日任务在 3 月 2 日凌晨 2 点运行时业务日期是 3 月 1 日。这个偏移量是所有离线数仓的基础约定理解错了会导致全链路取错分区。参数写法取值含义补数据时的行为${bdp.system.bizdate}业务日期格式 yyyymmdd按补数据指定的日期逐天取值${bdp.system.cyctime}实例的定时运行时间格式 yyyymmddhhmmss跟随实例时间变化${yyyyMMdd}自定义格式取业务日期同上仅格式不同${bdp.system.period}调度周期标识一般用于日志打标实际写 SQL 时分区过滤统一用业务日期-- 加工明细层从贴源层按业务日期取数写入同日分区 INSERT OVERWRITE TABLE dwd_user_action PARTITION (dt ${bdp.system.bizdate}) SELECT user_id, action, ts, from_unixtime(CAST(ts / 1000 AS BIGINT), yyyy-MM-dd HH:mm:ss) AS action_time FROM ods_user_action WHERE dt ${bdp.system.bizdate} AND user_id IS NOT NULL;INSERT OVERWRITE配合分区重跑时只覆盖目标分区不会动其他日期的数据这是补数据安全的前提。WHERE dt ${bdp.system.bizdate}里的分区过滤一定要写成常量字符串比较不要写成函数包裹字段的形式否则分区裁剪会失效变成全表扫描。补数据是另一个高频误区。补数据会按你指定的日期区间逐天生成实例每个实例的${bdp.system.bizdate}取对应那一天。如果代码里写的是${bdp.system.cyctime}补数据时取的就不是你指定的历史日期而是补数据动作发生的时间结果是所有分区都写到了同一天。这个错误不会报错只会让数据静默错位事后核对时才发现分区是空的。4.4 血缘、版本、结构三个面板各自解决什么问题文档 5.3 节里的这三个功能经常被当成摆设其实各有明确用途。血缘面板解决的是“改这张表会影响谁”下线一个字段之前先看下游节点列表比翻代码可靠。版本面板解决的是“上周那版能跑现在这版跑不动了”对比两个版本的差异能快速定位是哪次改动引入的问题。结构面板解决的是“这个节点的输入输出到底是什么”尤其是脚本模式下字段映射写错的时候结构视图比看 JSON 快得多。我一般把这三个面板当日常动作每次发布前看一次血缘确认影响范围每次改动后存一个版本注释每次接手别人的节点先看结构。这三个动作加起来不超过两分钟能省掉后面几小时的排查。5. 避坑清单五类最容易翻车的现场记录5.1 数据源测试通过同步任务报连接超时现象数据源管理页面点“测试连通性”返回成功但同步任务一跑就报Communications link failure或连接超时重试几次偶尔能过。原因测试连通性和任务执行的发起方不是同一台机器。测试走的是控制台侧的网络路径任务走的是数据集成资源组所在的机器。资源组网段没加进目标库白名单或者资源组和目标库不在同一网段就会出现测试通、任务不通。解决找到数据集成资源组的网段加到目标库的白名单里跨网段场景确认路由策略用最小任务验证而不是依赖测试按钮的结论。5.2 改了代码没提交发布周期任务跑的还是旧逻辑现象开发环境里改了 SQL手工运行结果正确第二天看生产数据还是旧口径。原因标准模式下开发环境的修改必须提交并发布到生产才会进入周期调度。只在开发环境保存生产实例用的还是上一次发布的版本。解决把“提交 → 发布 → 确认生产节点版本号变化”当成一个不可拆的动作。发布后到运维中心看一次该节点的生产版本确认代码是最新的。这个检查我每次上线都做省过好几次事故。5.3 补数据把分区写重了现象补了三天数据之后发现其中一天的分区数据量翻倍。原因Writer 侧没开truncate或者用了INSERT INTO而不是INSERT OVERWRITE补数据重跑时是追加而不是覆盖。另一种情况是同一分区有多个任务写入后跑的覆盖先跑的数据变成残缺。解决写分区表一律用INSERT OVERWRITE ... PARTITION同步任务确认truncate语义补数据前先梳理该分区的写入方一个分区只允许一个任务负责。5.4 向导模式字段类型不匹配任务被脏数据打断现象同步任务跑到一半失败日志里出现类型转换异常源库和目标库字段看着都是“数字”。原因源库的 DECIMAL(10,2) 映射到目标库的 DOUBLE精度丢失后部分值变成NULL或科学计数法或者源库有0000-00-00这种非法日期目标库严格模式下直接拒绝。解决字段类型逐个核对金额类一律用 DECIMAL 显式指定精度不用浮点非法日期在querySql里用CASE WHEN过滤掉脏数据阈值不要设成 0先设一个小值观察日志里到底是什么数据被拦下。5.5 文档截图和现场界面对不上现象照着文档点某个菜单发现现场版本没有这个入口或者菜单位置不一样。原因V3.12.0 是产品版本号20200706 是文档版本号两者不同步。专有云现场的补丁级别可能高于或低于文档对应的基线界面会裁剪或挪位。解决以现场控制台为准文档只用来理解功能语义和参数含义不用来背菜单路径。遇到找不到的入口先在文档里搜功能名而不是菜单名。6. 把这份 PDF 变成可检索的本地手册切页、建索引、做版本对照纸质手册最大的问题是查不快。这份文档九百多页靠阅读器自带的搜索找一个参数名经常要翻七八个命中项才能定位到真正讲配置的那一段。我后来把 PDF 拆成按页的文本文件配一个关键词到页码的索引查配置的时间从几分钟压到十几秒。做法分三步。第一步按页导出文本文件名带页码# -layout 保留原始排版表格和缩进不会塌掉 # -f/-l 指定起止页逐页导出后文件名直接带页码 mkdir -p dw_doc/pages for p in $(seq 1 950); do pdftotext -layout -f $p -l $p \ DataWorks用户指南_V3.12.0_20200706.pdf \ dw_doc/pages/p$(printf %04d $p).txt 2/dev/null done # 统计哪些页是空的空页通常是插图页索引时跳过 find dw_doc/pages -name *.txt -size -1k | wc -l-layout这个参数很关键不加的话表格会被打散成一列一列的文字参数表基本没法读。printf %04d补零是为了让文件名按字典序排序时就是页码顺序后面遍历不用额外排序。空页统计是为了建索引时排除掉不然搜出来一堆空白命中。第二步建一个极简的关键词索引不用引入任何检索库一个字典加 JSON 落盘就够import json import pathlib import re # 只保留有意义的词英文参数名、中文功能名、下划线配置项 TOKEN re.compile(r[A-Za-z_][A-Za-z0-9_.]{2,}|[\u4e00-\u9fa5]{2,8}) index {} for f in sorted(pathlib.Path(dw_doc/pages).glob(p*.txt)): page int(f.stem[1:]) text f.read_text(encodingutf-8, errorsignore) for tok in set(TOKEN.findall(text)): index.setdefault(tok.lower(), set()).add(page) # set 不能直接序列化转成排序后的列表方便人工看页码分布 json.dump({k: sorted(v) for k, v in index.items()}, open(dw_doc/index.json, w, encodingutf-8), ensure_asciiFalse)正则里的两段分别抓英文标识符和中文词组。英文部分限制最小长度 3是为了过滤掉dt、id这类噪音词中文部分限制 2 到 8 个字是因为中文没有分词抓太长会把整句吞进去。索引值用set去重同一个词在一页里出现十次也只记一次页码。落盘前转成排序列表是因为 JSON 不支持集合。第三步就是日常用法配合rg直接定位# 查某个配置项的原始说明-n 显示行号方便回到 PDF 对应位置 rg -n --no-heading splitPk dw_doc/pages/ | head -20 # 查中文功能名确认它在哪几页被讲到 python -c import json idx json.load(open(dw_doc/index.json)) print(idx.get(数据源隔离, [])[:20]) 这里有个我踩过的坑文档的目录页码和 PDF 的实际页码有偏移因为前面有法律声明和通用约定几页用了罗马数字。所以索引里存的必须是 PDF 物理页码不是目录上印的页码。搜到结果后按物理页码翻一次就能对上。最后贴一张我常用的检索对照表现场遇到问题时直接按左列找关键词现场症状检索关键词大概率命中章节同步任务连不上库测试连通性、数据源隔离、白名单数据集成 / 数据源配置周期任务不按时间跑调度参数、bizdate、依赖数据开发 / 周期与依赖字段类型对不上类型转换、字段映射、Reader数据集成 / 脚本模式配置任务排队久资源组、并发、限流数据集成 / 优化配置数据写重了truncate、分区、覆盖写数据集成 / Writer 插件这套东西做完之后最大的变化不是查得快了而是我开始愿意去查。以前遇到一个不熟的参数凭经验猜一个值就上了现在花十五秒搜一下能看到文档里对取值范围的明确说明。从那以后我每次接手一份超过三百页的产品手册都强制先走一遍切页建索引再动别的。这活儿看着笨但它是唯一能让你在半年后还记得“当时是在哪一页看到这个限制”的办法。希望帮到你。本文还有配套的精品资源点击获取