简介：这是一款面向Mangos服务端的数据编辑软件包，主要帮助魔兽世界私服架设者与核心研究者快速修改物品、任务、BOSS、NPC等游戏数据。包内可视化编辑器可直接连接Mangos数据库，读取并编辑物品属性、任务链、BOSS掉落、NPC刷新等核心内容，同时提供多语言界面切换，通过导入和操作CSV/SQL文件即可完成多种配置，无需逐条手工修改数据库。压缩包共66个文件，约1.63MB，其中55个CSV数据表覆盖职业、技能、地图、生物、任务、阵营、装备与掉落等多个维度，5个LNG语言文件支持多语言界面，另有SQL脚本、DLL运行库、EXE主程序、TXT说明文件和界面位图，结构清晰便于上手。借助CSV预置枚举与SQL批量更新机制，可大幅降低数据维护门槛，加之体积小巧，尤其适合需要频繁调整游戏数值与脚本逻辑的私服开发场景。目前已有927人学习下载，适合具备一定Mangos与数据库基础、希望提升数据管理效率的开发者深入学习。
1. Mangos的改机工作流，其实是从改数据库开始的
看到“Mangos物品、任务、BOSS、NPC等编辑软件”这个标题，你可能会以为它是一个绿色的单机修改器，双击就能改游戏。实际上，Mangos环境的物品、任务、生物和BOSS都不是写在客户端里的，而是躺在服务端数据库的几十张表里。这套“编辑软件”的价值，是帮你把改动落到这些表上，而不是替你写补丁。适合那些已经把Mangos跑起来、准备调整平衡性或副本难度的服务端维护者，也适合想彻底搞懂模拟器数据结构的入门玩家。一个反直觉的结论：真正耗时间的不是找工具，而是搞清楚哪张表管什么、改完之后为什么没生效。
2. 先摸清Mangos的“表格地图”：物品、任务、BOSS、NPC哪来的
2.1 物品表和生物表是根，DBC只是门面
在Mangos里，一件玩家能看到的物品，最终都要落到item_template这张表上。无论你用的是图形化编辑工具还是手动写SQL，最后执行的都是对这张表的UPDATE或INSERT。item_template的字段非常多，但真正决定一件装备“能不能用”的，主要是entry（唯一编号）、class（物品种类）、subclass（子类）、name（名称）、displayid（模型编号）、Quality（品质）、bonding（绑定类型）和stats这一系列属性字段。新手最常见的误区是只改name和displayid，却发现进游戏后客户端显示的名字还是老样子，那是因为客户端语言包不一定只读这张表。
NPC和BOSS同样集中在creature_template里，所有能被刷出来的非玩家角色都靠这张表驱动。entry、name、minlevel、maxlevel、faction（阵营）、rank、minhealth、maxhealth、mindamage、maxdamage、attackpower、armor这些字段组成了一个生物的骨架。其中rank字段特别值得注意：0 是普通小怪，1 是精英，2 是稀有精英，3 是BOSS。很多人在做BOSS时只调整血量，却忘了把rank改成 3，导致BOSS插件和成就系统完全不认。Mangos的数据库里没有单独的“BOSS表”，BOSS就是一种rank=3的生物，它的技能、AI、掉落分别由其它表关联。
2.2 任务的“链式关系”：quest_template加脚本
任务数据主要存在quest_template，一个任务的所有基础属性都在这里：entry（任务编号）、Title（标题）、QuestLevel（任务等级）、MinLevel（最低接取等级）、QuestDescription（任务描述）、RequiredNpcOrGo系列的收集/击杀目标、RewardXX系列的奖励。但任务不是孤立存在的，它跟NPC和物品之间的关系分散在creature_questrelation、gameobject_questrelation和creature_involvedrelation这几张关联表里。也就是说，你要给某个NPC加一个任务，光写quest_template不够，还得在关联表里加一条记录，指明“这个NPC能提供这个任务”。
从理论上说，Mangos的任务系统是“头表 + 关系表 + 脚本”三层：quest_template是头表，creature_questrelation是任务与NPC的挂接表，而脚本（通常在scripts或者数据库的quest_end_scripts里）负责任务完成后触发的动作。用编辑软件改任务时，一定要确认它是不是同时更新了这几层。很多号称能编辑任务的工具只改了头表，结果接不到任务，或者接了任务交不了。如果你只是手动写SQL，最稳的顺序是先插入quest_template，再插入creature_questrelation，最后插入creature_involvedrelation。只要少一条，任务链就可能断掉。
2.3 BOSS掉落与刷新：不能只改一张表
BOSS的战斗属性在creature_template里，但掉落数据的核心在creature_loot_template。这张表按生物entry关联掉落物，字段包括itemid、ChanceOrQuestChance（掉落几率/任务物品标志）、MinCount、MaxCount等。如果你只把creature_template里的生物血量改成100倍，却不碰掉落表，BOSS会变得难打但掉落没有任何变化。反过来，只改掉落表不调属性，BOSS很快就被推倒，掉落却没有成就感。所以做一个像样的BOSS，至少得同时看三块：creature_template的属性和rank、creature_loot_template的掉落、以及独立的洞穴/召唤脚本。
刷新位置则是另一张表creature（注意和creature_template的区别）。creature_template是“物种模板”，creature是“实例”。同一个BOSS可以有多个刷新点，对应多条creature记录。每条记录有guid（全局唯一ID）、id（引用模板）、map（地图ID）、position_x、position_y、position_z、orientation、spawntimesecs（刷新时间）等字段。修改BOSS刷新位置，改的是creature表而不是creature_template。这是整个Mangos数据体系中最容易混淆的一对概念，没有之一。搞不清模板和实例的区别，后面所有编辑都会遇到“改了没变”或者“变了引起奇怪问题”的麻烦。
3. 搭建可编辑环境：备份、连接、工具选择
3.1 解压后先做的三件事：备份、确认版本、清理旧习惯
从网上下下来的“编辑软件.rar”，里面可能是独立的GUI程序，也可能只是一套SQL脚本加说明文档。我习惯的做法是，第一步永远不是双击打开软件，而是先给数据库做一次完整备份。Mangos的数据库一般分realmd、mangos、characters三个库，物品、任务、生物数据都在mangos库里。只需要备份它就行：
mysqldump -uroot -p --databases mangos --single-transaction --quick --skip-lock-tables > mangos_backup_$(date +%Y%m%d).sql这个命令里的--single-transaction是保证备份过程中不锁表，对正在跑的服务端影响最小；--quick适合导出大表；--skip-lock-tables避免因为表被占用而中断。备份文件要存到一个和压缩包不同的目录，不要放在服务端程序目录下，防止重启时被清掉。做完备份后，第二步是确认数据库版本。Mangos有从老旧的Classic到后续的TBC、WotLK等不同核心分支，数据库表结构差异很大。如果你手上的编辑软件是给TBC核心用的，硬拿去连WotLK的库，很可能连creature_template的字段都对不上，轻则报错，重则写坏数据。
第三步是清理旧习惯。很多人习惯直接在线改库，改完立刻重启服务端。这非常危险。因为Mangos启动时会缓存大量数据库内容到内存里，你的UPDATE语句可能在启动时被缓存覆盖。更安全的工作流是：离线改库 → 重启服务端 → 验证。如果是小修改，也可以用在线热更新命令，但前提是你熟悉每个修改的副作用。我见过太多人在同一个表上反复改，最后数据变得一团糟，只能靠备份回滚，这时候“后悔药”就是前面那一步备份。
3.2 图形化编辑器和纯SQL脚本怎么选
标题里叫“编辑软件”，但实际拿到手后你会发现，这类软件要么是包装得很厚的界面，要么只是一堆.sql脚本 + 一个简易工具。真正从业余到专业，大多数Mangos维护者最后都回到“数据库客户端 + 自写SQL”这条路。图形化编辑器的优势是字段名有中文注释，点几下就能改，但它的缺陷也很明显：升级核心后，表结构一变，旧编辑器就失效；而且它很难批量改，一次要改100个怪的掉落，靠手工点击会让你崩溃。纯SQL脚本虽然看起来硬核，但可复用、可批量、可控性高，出问题也容易排查。
我的选择是分场景：如果只是临时看一眼某个物品的字段，用图形化工具直接查；如果要调整整个副本的掉落或者批量修改怪物等级，一定用SQL脚本。这就像修电路，用万用表点和整条线路改线是两种活儿。压缩包里带的说明文档如果提到“先导入update.sql”，那多半意味着它本身不是一个独立程序，而是让你在数据库客户端里执行脚本。那你要准备的就不是“更多软件”，而是一个能连MySQL的工具，比如Navicat、HeidiSQL或者命令行mysql。
3.3 最小可运行的一组连接参数与验证SQL
不管用哪种工具，先得让编辑软件连上数据库。Mangos默认的数据库账号配置在mangosd.conf里，常见配置段如下：
LoginDatabaseInfo = "127.0.0.1:3306;root;root;realmd" WorldDatabaseInfo = "127.0.0.1:3306;root;root;mangos" CharacterDatabaseInfo = "127.0.0.1:3306;root;root;characters"这里的格式是“地址:端口;用户名;密码;库名”。推荐先用工具做一次连通性检查，如果连接失败，优先看端口、账号密码、MySQL是否启动，而不是怀疑编辑软件有问题。连通后，执行第一条验证SQL：
SELECT COUNT(*) AS item_count, MAX(entry) AS max_entry FROM mangos.item_template; SELECT COUNT(*) AS creature_count, MAX(entry) AS max_entry FROM mangos.creature_template;这两条语句能立刻告诉你当前库里的数据规模，以及最关键的表主键上限。后面你要用INSERT插入新物品、新BOSS时，max_entry决定了你该从哪个编号开始。如果这个数字是几百，你可以放心用一万以上的编号做自定义内容；如果已经是几百万，说明这个库可能被人改过，你需要小心选择编号段位，避免与后续官方内容冲突。这一步相当于给你的编辑工作划定“安全区”。
4. 动手改：物品、任务、BOSS、NPC的四个实战脚本
4.1 改一件物品：让“传说之剑”变成真实掉落
假设你想把entry=38632的剑改成一把属性超模的传说武器。先查一下它现在的值，不要凭记忆乱写：
SELECT entry, name, Quality, ItemLevel, bonding, displayid, maxcount, delay, damage_type FROM item_template WHERE entry = 38632;看到结果后，用一个UPDATE修改核心字段：
UPDATE item_template SET Quality = 5, ItemLevel = 284, bonding = 1, displayid = 50731, armor = 0, dmg_min1 = 800, dmg_max1 = 1200, delay = 240, maxcount = 0 WHERE entry = 38632;这段SQL的逻辑很清楚：Quality=5是传说品质（橙色）；bonding=1是拾取绑定，防止交易；displayid换成拉风的模型；dmg_min1和dmg_max1是上下限伤害；delay是攻速毫秒值，240 表示 2.4 秒；maxcount=0表示不叠加。但只有这些字段还不够，物品往往还关联技能触发、职业限制和附加属性。如果你想保留原物品的其它属性，最稳妥的方式是先INSERT一整行作为副本，再对新entry修改。复制一行在SQL里并不难：
INSERT INTO item_template SELECT * FROM item_template WHERE entry = 38632; SET @new_entry = 49999; UPDATE item_template SET entry = @new_entry, name = '传说中的血色之刃', description = '只属于你的乱改版' WHERE entry = @new_entry;这里有个关键坑：item_template的主键是entry，直接SELECT *复制出来的新行会和原件共享同一个主键，所以必须先插入（此时因为主键冲突会报错？实际上需要先改掉自增）。正确做法是先修改复制出来的中间表或直接插入时指定新ID。更常见的是用“先查原行ID，再改ID”的方式，这就需要小心操作：
CREATE TEMPORARY TABLE tmp_item SELECT * FROM item_template WHERE entry = 38632; UPDATE tmp_item SET entry = 49999; INSERT INTO item_template SELECT * FROM tmp_item; DROP TEMPORARY TABLE tmp_item;这段脚本先复制到临时表，然后把临时表的主键改成新值，最后插入。为什么不直接用INSERT ... SELECT加ON DUPLICATE KEY？因为entry直接被新值替代更直观，而且临时表可以让你在插入前再检查一遍字段是否有错。复制新人后，原来物品的各类关联数据（比如掉落、任务奖励）都会跟着新entry走，点击保存前务必确认name和description是你要的。
4.2 改一个任务：调整需求和奖励
任务修改不能只看quest_template。比如你想把一个“收集10个蝙蝠牙”的任务改成“击杀一个BOSS”。先找到原任务：
SELECT entry, Title, QuestLevel, RequiredNpcOrGo1, RequiredNpcOrGoCount1, RewardItem1, RewardItemCount1 FROM quest_template WHERE entry = 12345;然后分别更新目标类型和奖励：
UPDATE quest_template SET RequiredNpcOrGo1 = 49999, RequiredNpcOrGoCount1 = 1, RequiredNpcOrGo2 = 0, RequiredNpcOrGoCount2 = 0, RewardedItem1 = 49999, RewardedItemCount1 = 1 WHERE entry = 12345;注意RequiredNpcOrGo字段约定：如果是负值，表示要交互一个gameobject；如果是正值，表示击杀或击杀一个creature。例如RequiredNpcOrGo1 = -50001就是让玩家去关闭某扇门，而= 49999就是击杀那个BOSS。很多新手把正负号写反，导致任务一直不能完成。RewardedItem里填物品entry，RewardedItemCount是数量。但别忘了一个隐藏坑：任务完成后是否有后续任务，以及任务给予者是否在对应地图。这时需要查关联表：
SELECT * FROM creature_questrelation WHERE quest = 12345; SELECT * FROM creature_involvedrelation WHERE quest = 12345;如果没有返回记录，说明区服里没有任何NPC给出这个任务，那你改的目标再准也接不到。解决方法是插入一条对应NPC的关联记录：
INSERT INTO creature_questrelation VALUES (38632, 12345); INSERT INTO creature_involvedrelation VALUES (38632, 12345);这两个插入分别让entry=38632的NPC成为任务的“开始者”和“结束者”。不要以为它们是一样的，前者管接任务，后者管交任务。很多编辑软件号称“任务一条龙”，实际上只生成了头表和开始关系，忘了结束关系，最后玩家做完任务交不了。验证一张任务表的完整度，至少要看这三张表都有记录，并且quest_template里QuestType没有异常。
4.3 改BOSS：血量、技能和掉落
一个BOSS本质上是creature_template的特殊行。改BOSS最直接的是调它的基础属性：
UPDATE creature_template SET minlevel = 83, maxlevel = 83, rank = 3, minhealth = 5000000, maxhealth = 5000000, minmana = 500000, maxmana = 500000, faction = 16, attackpower = 1000, armor = 15000, mindamage = 5000, maxdamage = 8000 WHERE entry = 49999;在这个更新里，rank=3是BOSS的身份证；faction=16通常是敌对阵营，如果不改，BOSS可能中立，进副本后站在那儿发呆；minhealth和maxhealth用一个保险的做法是设成相同数值，确保每次进本血线一致，不会因为随机范围造成开荒难度波动。改完属性，BOSS的技能不在这个表里。Mangos的生物技能关联通常在creature_ai_scripts（老版）或smart_scripts（新版核心支持）中，也可以由boss_XX_template或mangos_string控制。最稳的做法是查看同地图BOSS模板，复制它的技能组。
掉落是另一个独立表。假设BOSS的entry=49999，你希望它掉落某件自定义物品：
INSERT INTO creature_loot_template (entry, itemid, ChanceOrQuestChance, MinCount, MaxCount) VALUES (49999, 49999, 20, 1, 1);20是20%的独立掉落几率，每次只掉1件。如果你想让“每次必掉2～3件”，可以写成：
UPDATE creature_loot_template SET ChanceOrQuestChance = 100, MinCount = 2, MaxCount = 3 WHERE entry = 49999 AND itemid = 49999;注意ChanceOrQuestChance用途是双重的：正值是掉率百分比，负值是任务物品掉落，此时MinCount是掉几件任务物品。很多人把这个字段改成负数想做成任务道具，却忘记了玩家任务是“收集3个”，结果杀掉BOSS后地上只掉了一堆任务物品无法拾取。这样反而会卡任务进度。所以任务类的掉落，ChanceOrQuestChance设为-100，MinCount设为任务所需数量。
4.4 改NPC刷新：坐标、数量与刷新间隔
前面说过“实例表”creature管具体刷新。你想把某个城市里的卫兵数量增加一倍，得先看它现有的位置：
SELECT guid, id, map, position_x, position_y, position_z, orientation, spawntimesecs FROM creature WHERE id = 38632 AND map = 0;然后复制一条新的刷新点，比如在原来位置旁边20码处：
INSERT INTO creature (guid, id, map, position_x, position_y, position_z, orientation, spawntimesecs) SELECT (SELECT MAX(guid) + 1 FROM creature), 38632, 0, 1.5 * position_x, 1.5 * position_y, 1.5 * position_z, orientation, spawntimesecs FROM creature WHERE guid = 12345 AND id = 38632;这里用了MAX(guid) + 1来手动生成新ID，因为creature表的guid通常不是自增，而是核心维护的键。用INSERT INTO ... SELECT从原行复制能保证map、orientation、spawntimesecs这些值不会漏掉。关键参数是spawntimesecs：小怪一般设60～300秒，BOSS建议7200以上，几小时刷新一次比较合理。如果你想让一个BOSS永不刷新，设置为0即可，但那通常会让玩家打完一次就没得打。
刷新条数也需要注意：同一id的多条creature记录，只要位置不冲突，就可以共存。但如果你在表里看到大量位置叠在一起的记录，那多半是从前的人在UI里误点了“刷怪”，导致同样坐标叠了几十只怪，进游戏会卡成幻灯片。正确做法是先改已有记录的坐标，而不是一直插入。定位“重复坐标”的时候用这条SQL：
SELECT id, position_x, position_y, position_z, COUNT(*) AS cnt FROM creature GROUP BY id, position_x, position_y, position_z HAVING cnt > 1;这个语句会列出所有同位置重复刷新的组合。看到结果后，把多出来的记录的position_x加上一个偏移量，比如position_x + 2.0，让它们错开一点位置。如果错开太远看起来像散兵，就按环形梯度调整。
5. 编辑软件绕不开的坑：缓存、清缓存和回滚
5.1 改完数据库不生效，先清服务端缓存和客户端缓存
现象：你把item_template的name改了，重启mangosd，进游戏看还是旧名字。原因通常不是数据库没改，而是服务端启动时把item_template加载到了内存缓存，而部分核心不会每次查询都重新加载。解决方法是先确认SQL是否生效（在数据库中直接查），然后重启服务端。另一个藏得更深的缓存是客户端Cache目录。魔兽客户端会缓存物品和生物的DBC信息，如果你的修改只涉及item_template而被客户端覆盖，就得清掉客户端的Cache、WDB或WTF里的缓存目录。我常用命令：
rm -rf /opt/wow-client/Cache /opt/wow-client/WDB /opt/wow-client/WTF/*.wtf如果你是在Windows上跑客户端，路径通常是C:\World of Warcraft\Cache，记得先备份WTF里的角色设置。清缓存后重启客户端才干净。
5.2 entry主键冲突：复制现有条目比新建快
现象：插入新物品或新生物时，工具报Duplicate entry '38632' for key 'PRIMARY'。原因是你从原行复制时忘了改主键，或者随手填了一个已经存在的entry。处理办法是不要硬写一个不存在的天上数字，而是用前面介绍的“临时表复制法”，并在复制后立刻把主键改成空闲值。查空闲值：
SELECT MAX(entry) + 1 AS next_free_entry FROM item_template;但是简单MAX(entry)+1在大量删除后可能不是真正空闲的。为了保险，用一张号码段表，或者统计出一段完全没有被占用的范围：
SELECT MIN(t1.entry + 1) AS next_id FROM item_template t1 WHERE NOT EXISTS (SELECT 1 FROM item_template t2 WHERE t2.entry = t1.entry + 1);这条读取效率不高，但适合做一次性的主键规划。实用做法是给自己划一块“自定义段位”，比如60000到70000之间，专门放自己添加的内容。这样就算未来官方内容更新，也不会误撞你的entry。
5.3 坐标写错NPC上天入地：用附近地面点修正
现象：插入的NPC刷新后跑到天上或者卡在地下一半的位置。原因是你直接从地图编辑器里复制的坐标，或者手动填了position_z但没有对准地形。解决方法是不要凭空猜坐标，用同地图已有的NPC作为参照：
SELECT guid, map, position_x, position_y, position_z, orientation FROM creature WHERE map = 0 AND id = 38632 LIMIT 3;把返回的position_z当作基准，再在它的基础上微调。如果你改的是水下生物，还要注意position_z一定要低于水面高度。另一个办法是使用游戏内GM命令.go xyz走到目标点，再.gps查精确坐标，然后写回数据库。实测下来，.gps最准，不要相信人眼估算。
5.4 编辑工具连不上库：账号权限和绑定问题
现象：用“编辑软件”连接数据库时报Access denied或Host 'xxx' is not allowed。原因大多是MySQL账号权限不足，或者账号只允许localhost登录。解决方法是先在命令行里授予权限：
mysql -uroot -p -e "GRANT ALL PRIVILEGES ON *.* TO 'mangos'@'192.168.%' IDENTIFIED BY 'yourpass'; FLUSH PRIVILEGES;"如果你用的是本地回环地址，@'localhost'就够了。但如果你把编辑软件放在另一台机器上，就必须写一个可远程连接的权限。这一个命令能解决大部分“连不上”的问题。还有一种是导入SQL脚本时遇到Unknown table 'db'这类报错，那通常是你还没选定数据库，直接在命令行执行了USE mangos;或者没有加库名前缀。解决办法是在每条SQL前都带上库名，比如mangos.item_template，或者用数据库客户端的“切换到库”功能。
5.5 物品中文名被覆盖：改的是客户端的本地化字段
现象：你在item_template.name里写了一个中文名，重启后客户端显示的名字是英文或者显示成乱码。原因是Mangos的本地化字段分散在不同的locales_*表里，比如locales_item、locales_creature、locales_quest。客户端显示时优先读本地化表，缺了才回退到基础表。解决方法是同步修改本地化表：
INSERT INTO locales_item (entry, name_loc8, description_loc8) VALUES (49999, '传说中的血色之刃', '一把被乱改出来的武器') ON DUPLICATE KEY UPDATE name_loc8 = VALUES(name_loc8), description_loc8 = VALUES(description_loc8);这里的name_loc8中的loc8是简体中文的区域代码。KLOC（本地化代码）loc0是英文，loc8是中文。如果你只改基础表，大部分核心在中文客户端下依然会显示旧内容。这个坑几乎每个做汉化的人都会遇到。同理，修改BOSS名称、NPC称号、任务目标描述时也别只改一张表，要全线检查相关的locales_表。
6. 验证你的修改：不只是重启服务端
到这一步，你需要的不是再写一条UPDATE，而是建立一套验证习惯。我每次改完内容，至少会去执行三条命令。第一条是查数据库里的当前行，确认字段真的写进去了：SELECT * FROM item_template WHERE entry = 49999;。第二条是重启服务端后立即看日志，Mangos启动日志中如果有ObjectMgr::LoadItemTemplates相关的报错，表格结构多半有问题。第三条是进游戏用GM命令.lookup item 传说中的血色之刃搜索到新物品，然后.additem 49999给自己发一件，穿上后看属性面板是否和预期一致。
关于BOSS验证，我会习惯性打开掉落日志。在mangosd.conf里把DPS_DAMAGE_LOG或MESSAGE_SEND相关开关临时打开，杀一次BOSS，日志里会打印掉落列表。这个小技巧帮我抓过很多次“掉率配了但实际没掉”的问题。一次教训让我长记性：某次我调整过一个BOSS的血量，顺手把creature_loot_template里某件物品的ChanceOrQuestChance从100改成了50，但忘了检查QuestLoot字段是否还要同步，导致任务物品不再掉落，玩家卡了一下午。后来每次改掉率，我都先把原始值记在注释里，并写一条UPDATE的反向恢复记录，相当于给改库加了“撤销”。
批量验证也有一个讨巧的办法：把所有改过的entry汇总成一个临时表，然后用几个LEFT JOIN检查引用完整性，看有没有悬空的物品或生物引用：
SELECT l.entry, l.itemid, t.entry AS missing_item FROM creature_loot_template l LEFT JOIN item_template t ON l.itemid = t.entry WHERE l.entry = 49999 AND t.entry IS NULL;这条查询能找出掉落了但item_template里不存在的物品，防止玩家捡到“空气”。这套方法虽然简单，但远比“拍脑袋改完再重启”可靠。最后送你一句我的习惯：任何一次编辑前，先把当前数据导出到一个.sql备份，改完给它备注上日期和目的。哪怕在尝试阶段翻车十次，只要还有备份，就能十分钟回到原点。希望这些经验能帮你在Mangos的编辑路上少走弯路。
本文还有配套的精品资源，点击获取
