企业官网建设流程全解析

简介：游戏服务端是MMORPG的灵魂，其架构设计直接影响玩家体验。开源模拟器则为开发者提供了学习与实践的绝佳平台。基于C#和.NET技术栈的ServUO，作为经典游戏《网络创世纪》（UO）的模拟器服务端，不仅延续了RunUO的稳定架构，更通过现代框架优化提升了跨平台兼容性与脚本热重载能力。文章从服务端同步原理、世界状态管理、持久化机制等基础概念切入，逐步详解ServUO的环境部署、配置文件修改、管理员账号创建及公网开放流程，并深入技能、物品、NPC与经济系统的脚本定制，同时涵盖编译报错、连接失败、存档损坏等常见问题的排查技巧。无论是怀旧玩家希望搭建单机或社区服，还是开发者想要研究大型游戏服务端架构，ServUO都提供了一个功能完善、易于扩展的实践入口，是连接经典玩法与现代工程技术的桥梁。 如果提起《Ultima Online》，老玩家脑海里多半会浮现在不列颠尼亚大陆上砍木头、挖矿、被红名追杀的日子。这款1997年发售的MMORPG鼻祖，奠定了无数后世网游的设计逻辑，而项目标题里的 ServUO，正是这套经典游戏在开源世界里最重要的一支模拟器分支。作为一个常年折腾UO服务器端的爱好者，我可以直接说：ServUO是目前搭建UO服务端最省心、文档最全、社区最活跃的选择之一。这篇内容我不打算讲太多虚的，直接从一个可运行的视角出发，拆解ServUO的结构、部署、玩法和二次开发思路，让你拿到手就能跑起来，跑起来后还能自己改出想要的样子。

这篇文章适合三类人：一是怀旧玩家，想自己搭个单机或小圈子服务器重温经典；二是UO私服的运营者，想从RunUO老版本迁移过来；三是游戏服务端开发的新手，想研究一个完整MMORPG服务端是怎么组织的。

1. 项目解析：ServUO到底是什么

1.1 从RunUO到ServUO的血统与差异

要理解ServUO，绕不开RunUO。RunUO是早期最著名的UO服务端模拟器，发布于2004年前后，几乎以一己之力激活了整个UO私服生态。但RunUO在2010年之后就基本停止了大版本更新，代码停留在.NET Framework 2.0时代，对新操作系统、新客户端版本支持很吃力。

ServUO就是从这个分支里长出来的。它继承了RunUO的核心架构，但做了几件关键的事：将代码升级到.NET 4.x甚至.NET Core，修掉了大量内存泄漏和老旧的线程写法，加入了更强的事件系统和脚本热重载能力。更重要的一点是，ServUO能兼容更多客户端版本，从老旧的7.0.x到新一些的客户端都能支持，这就让玩家不必为了上服而专门去降级客户端。

从实操角度讲，如果你只在RunUO和ServUO之间犹豫，我的建议很直接：新项目一律选ServUO。RunUO最大的问题不是功能少，而是它的底层对现代硬件和系统兼容性太差，跑在Windows Server 2022或Ubuntu 22.04上经常出现莫名其妙的崩溃，而ServUO在这些环境里跑得很稳。

1.2 技术栈一览：C#与.NET的经典组合

ServUO整个服务端是纯C#写的，运行在.NET运行时之上。这个技术选型意味着两件事：第一，跨平台很容易，Windows、Linux、macOS都能跑；第二，二开门槛不算高，懂一点C#就能写脚本，不需要学一门生僻的脚本语言。

来看一下整个仓库的核心目录结构，这决定了你后续开发时要在哪里找东西：

• Scripts目录：核心游戏逻辑，所有物品、NPC、技能、任务都在这。
• Server目录：服务端的底层框架，网络、线程、持久化、指令系统。
• Data目录：存放地图、汉化文本、技能配置等静态数据。
• Config目录：服务器运行的配置文件，比如端口、最大在线人数。
• Ultima.dll项目：负责读取客户端数据文件（如地图块、静态元素），是客户端与服务端同步世界图景的关键桥梁。

我第一次看这个仓库时，最直观的感受就是：Server和Scripts的边界非常清晰。Server是引擎，Scripts是内容，这种低耦合设计让多人协作开发成为可能——引擎组和内容组可以并行工作，互不阻塞。

1.3 这个项目能做什么：从单机到社区服

很多人以为ServUO只能做官服复刻，其实它的能力远不止这些。基于ServUO的服务端，你可以搭建出不同形态的玩法：

• 单机怀旧服：自己一个人探索不列颠尼亚，调GM命令刷装备，体验所有Boss和任务。
• 小圈子合作服：几个朋友一起玩，加大资源倍率，减少练级痛苦，专注于PVE。
• 大型社区服：公开运营，设置阵营PK、排位赛季、自定义节日活动、拍卖行等。
• 魔改版：完全替换职业体系、技能树、装备数值，做出一个看起来不太像UO但底层仍是UO的玩法。

实际生态里，这三类服都存在。有些知名的大型UO私服，核心就是ServUO加大量自定义脚本，甚至做到了每年一个大型资料片的更新节奏。也就是说，ServUO的能力上限不是引擎决定的，而是你的想象力决定的。

2. 核心机制拆解：服务端如何撑起一整片大陆

2.1 客户端与服务端的同步原理

UO的客户端和服务端通信方式，和现在的主流网游不太一样。现在的网游大多是状态同步，服务器只下发关键状态；而UO是典型的指令流同步，客户端每做一个动作，都会把指令通过socket发送给服务端，服务端经过校验和逻辑处理后，再把结果广播给视野内的所有玩家。

ServUO的通信层做了很好的封装。网络层使用自定义的Socket封装，支持TCP长连接，默认端口是2593。每个客户端连接对应一个NetState对象，这个对象生命周期管理很讲究：登录、心跳、断线、封包加密都在这里面处理。

想要理解心跳机制，可以类比成你和朋友打电话时每隔几秒"喂"一声，确认对方还在听。UO客户端的默认心跳间隔大约是30秒到60秒，如果服务器长时间没收到心跳包，就会把这个连接标记为超时并断开，释放对应的资源。

2.2 世界状态的管理方式

UO的世界是一个2.5D俯视角地图，分为多个地图块（Map），每一块又切成固定大小的区块（Region）。ServUO在世界管理上大量使用区域划分的思维：每个玩家、NPC、物品都会注册到一个或多个Region里，服务器在每帧更新时只遍历活跃区域，而不是扫描整个世界。

这种设计的收益非常明显。一个在线500人的服务器，如果每次行动都全图广播，网络包会瞬间爆炸；而区域广播就能把数据量控制在一个很小的范围内。打个比方：你在自家院子里喊一嗓子，整条街的人其实不需要全都听到，邻居听到就够了。

2.3 持久化机制：存档怎么做到不崩坏

玩UO私服最怕的事就是回档。ServUO的存档机制默认是保存一个二进制格式的世界快照，通常存在Saves文件夹中，文件名字类似SaveData.bin。服务器运行中，会自动按设定的WorldSaveInterval（默认5分钟）周期性将内存中的世界状态写入磁盘。

这份二进制存档涵盖的内容包括：所有玩家的角色数据、银行容器、装备耐久、技能经验值、房屋地基、箱子里的物品坐标，以及NPC的刷新状态。信息量非常大，所以存档文件有时候会到几百MB。写入过程中如果服务器崩溃，就会产生一个不完整的存档，导致下次启动读取失败。

为了应对这个问题，ServUO有两种额外机制：一种是Archive，即每次存完档把旧存档压缩备份，默认保留近几份；另一种是Change Timestamp，即对关键容器做增量标记，下次读取时只重新加载有变动的数据。这套机制实践下来相当可靠，但前提是你记得定期把Saves目录整体复制到别的硬盘。

3. 从零搭建：本地跑起第一个ServUO服务器

3.1 环境准备清单

ServUO对运行环境的要求其实不算高，但有几个前提条件必须满足：

• 操作系统：Windows 10/11、Windows Server 2016/2019/2022、Ubuntu 20.04/22.04,或者macOS 12+
• .NET运行时：注意，不同分支要求不同。master分支一般要求.NET 6或.NET 7；如果是较老的分支，可能只支持.NET Framework 4.8。建议直接装最新.NET 8 SDK，Visual Studio或Rider做IDE。
• 客户端：准备一个对应版本的UO客户端文件，最好完整，包括map和mul文件。因为服务端需要读取客户端的图形数据和地图数据。
• Git：拉取仓库用。

我在Ubuntu上跑的时候，只装了dotnet-sdk-8.0和git,别的什么都不需要。Windows下则注意把.NET SDK的安装路径加进环境变量。

3.2 获取代码与首次编译

拉取代码的流程非常简单：

git clone https://github.com/ServUO/ServUO.git cd ServUO

仓库根目录下有解决方案文件，你可以直接用命令行编译，也可以用IDE打开。命令行方式最省事：

dotnet build -c Release

第一次编译通常要两分钟左右，取决于网络和机器性能。编译结束后，检查bin/Release目录下是否有ServUO.dll或可执行文件。在实际部署中，服务器启动的入口是ServUO.exe（Windows下）或通过dotnet Server.dll启动（Linux下）。

这里有个关键点：编译的时候，项目会自动探测本地是否安装了Ultima SDK依赖。如果你缺失了客户端数据文件的相关引用，编译会报错。常见的报错信息是找不到Ultima.dll或者Microsoft.Extensions.DependencyInjection相关的程序集。碰到这种情况，先跑一下dotnet restore，再重新build。

3.3 首次启动与配置文件修改

编译成功之后，先别急着把服务端扔到生产环境。第一次运行建议在本地，因为你要做的事还很多。

在Windows下直接运行编译产出的可执行文件，在Linux下执行dotnet Server.dll，启动后服务端会检测是否缺少配置文件，并且自动生成默认的配置文件。默认配置集中在Config目录，常见的关键项：

• Server.cfg：服务器名称、端口、IP绑定地址。
• World.cfg：世界存档间隔、存档文件位置。
• Game.cfg：经济参数、升级倍率、死亡掉落。

以Server.cfg为例，最核心的两个参数：

Address=127.0.0.1 Port=2593

如果你想对外开放访问，把Address改成0.0.0.0，然后在防火墙里放行2593端口。默认127.0.0.1只监听本地回环地址，别人连不进来。

首次启动后，服务端日志会输出大量初始化信息。观察日志尾部是否有World loaded successfully或者Server started之类的提示，说明核心引擎已经就绪。

3.4 创建管理员账号与玩家测试

服务端启动后，需要创建一个管理员账号才能在游戏里使用GM命令。这个过程是在服务端控制台完成的，不是在客户端。

在控制台输入：

[add account admin password Admin

这个指令的含义是创建一个账号admin，密码password，权限Admin。然后打开UO客户端，在登录界面输入服务器IP和端口，用这个账号登录即可。

首次进入游戏，你的角色会出现在默认的出生点。如果想要快速获取物品，可以用GM命令刷。比如在聊天框输入[add gold 100000给自己加金币，或者[add bagofsending刷一个工具袋。

基础命令不需要写脚本，直接在输入框输入即可。但这里有个坑：你必须先在客户端聊天输入框中切换到英文输入法，否则命令的[和]会被中文输入法拦截。

3.5 公网开放需要做的事

如果你的目标是让朋友在远程连接，只在本地跑还不够。你需要做三件事：

第一，修改Server.cfg的监听地址为0.0.0.0，确保服务端接受任意IP的连接。第二，在路由器上做端口转发，将外部端口（默认2593）映射到运行服务端的老机器的局域网IP上。第三，在安全组和防火墙规则里放行2593端口，否则即使外网能访问，防火墙也会直接丢弃数据包。

还有一个很多人不知道的细节：UO客户端的登录服务器和游戏服务器是分离的。也就是说，客户端先连接登录服务器（ListenPort通常是2593），登录验证通过后，再连接游戏服务器（GamePort默认也是2593）。如果登录服务器和游戏服务器配在不同的端口，需要保证两个端口都放行。

4. 玩法内容拆解：理解UO世界的地基

4.1 职业技能与角色成长

UO的技能体系在当下MMORPG里非常独特，它不设职业，而是用一套技能列表来定义角色。每个角色可以学习多种技能，技能总和有上限（默认700点，可配到720甚至更多）。技能的实际等级会影响角色的战斗、采集、制造能力。

ServUO的脚本里，每个技能都有独立的实现文件。比如Swordsmanship.cs处理剑术技能，Mining.cs处理采矿。每个技能的修炼逻辑在OnUse和OnCheck方法中实现，实际做操作时会根据当前技能值、操作目标品质、角色属性来计算成功率。

我试着在脚本里改过采矿的产出概率。在Mining.cs里找到CheckMiningSkill方法，把矿石生成的基础概率从默认的50%调成了80%，同时把高级矿石的保底系数拉高。改动后的效果是：玩家挖矿的挫败感显著降低，但高级矿物的产出数量并没有完全失控。这种小改动对玩家体验的影响非常直接，强烈建议服主多做这类调优。

4.2 物品系统的层次与装备设计

UO的物品系统可以拆成基础和属性两个层面。基础层面指物品的定义、ID、图形、堆叠性、容器归属等，对应脚本里继承Item类的各种子类；属性层面指伤害、命中、防御、速度等战斗数值。

ServUO引入了一套属性生成机制，装备的魔法属性是随机生成的。这类似于暗黑破坏神的词缀系统。在服务器配置里，有几个参数叫MagicItemChance、EnhancePrice、ImbuingChance，这些直接决定了玩家掉落的装备品质分布。

如果你运营的服务器偏PVE，可以适当调高MagicItemChance，让玩家刷Boss时更有捡到宝的感觉；如果偏PVP，则不能太高，否则装备差距过大，打架变成装备碾压。这是运营层面的取舍，没有绝对最优，只有适合你的玩家群体。

4.3 NPC与AI行为控制

UO世界里到处都是NPC，商人、银行家、守卫、怪物。ServUO为NPC实现了一套比较完整的AI状态机，主要分几种模式：

• AnimalAI：普通动物，遇到玩家会逃跑。
• MeleeAI：近战型怪物，主动攻击玩家。
• RangedAI：远程型怪物，保持距离的攻击。
• VendorAI：商人NPC，主要负责买卖对话。
• GuardAI：守卫，会追杀带有犯罪标记的玩家。

这些AI脚本都在Scripts/Mobiles/AI目录下。每种AI有类似Think、Act、DoAction的钩子方法，你在子类里重写它就能控制NPC行为。

有一个比较有代表性的例子：我曾在某次活动里想要做一个"逃跑的商人"NPC，玩家追上他才能买货。做法是重写MeleeAI的Think方法，让NPC在玩家靠近到一定距离时朝反方向跑，直到体力条消耗完才停下。整个过程不需要改客户端任何代码，服务端逻辑即可完成。

4.4 经济系统与拍卖行

UO的经济系统核心是玩家与商人NPC之间的交易。金币的产出主要靠卖战利品、做任务；消耗靠买装备、材料、修理工具。如果长期运营，你会发现经济最怕的事情是通胀：玩家手里的金币快速增多，但金币的消耗渠道不够，导致物价飞涨。

ServUO提供了一套基础的经济配置参数，比如商人收购物品的折旧比例、修理费用、锻造费用。这些在Economy.cs相关脚本里做统一管理。想解决通胀，除了调低掉落金币倍率，更有效的做法是增加金币回收渠道，比如增加高价值的NPC绑定物品、增加修理成本和传送费。

这里我踩过一个坑：早期开服时把金币掉落倍率调成官服的3倍，结果三个月后整个服务器物价翻了一倍多，新玩家根本追不上老玩家。后来不得不开了一个全服回收活动，用限定头衔换金币，才勉强把通胀压下来。想长期运营的服主，经济系统从一开始就得想清楚。

5. 二开实战：深入ServUO脚本系统

5.1 脚本目录怎么看

ServUO的Scripts目录是整个二开的主战场，它的组织方式按对象类型分了多个子目录：

• Items：所有道具、装备、容器、建筑。
• Mobiles：所有NPC、怪物、玩家角色扩展。
• Commands：GM命令和玩家命令的注册。
• Engines：任务、活动、副本、投票、小游戏等玩法。
• Spells：所有魔法技能。

在新增内容时，最佳实践是新建一个文件夹，比如Scripts/Custom/MyFunnyItems，把自己写的脚本放进去。这样既方便管理，又不会在升级Scripts核心内容时被覆盖。这一点非常重要，因为以后你拉取上游更新时，git pull可能会产生冲突，如果自定义脚本独立放在Custom里，冲突会少得多。

5.2 写一个简单的自定义物品：一把会发光的剑

下面演示一个最基础的自定义装备，你直接把它保存成.cs文件放到Scripts/Custom/目录，重编译后就能在游戏里用[add命令刷出来。

using System; using Server; using Server.Items; namespace Server.Custom { public class MyGlowingSword : Katana { public override string DefaultName { get { return "艾泽拉斯的余烬"; } } [Constructable] public MyGlowingSword() : base() { Hue = 38; // 橙色 WeaponAttributes.HitFireball = 50; Attributes.Luck = 100; Quality = WeaponQuality.Exceptional; } public MyGlowingSword(Serial serial) : base(serial) { } public override void Serialize(GenericWriter writer) { base.Serialize(writer); writer.Write((int)0); } public override void Deserialize(GenericReader reader) { base.Deserialize(reader); int version = reader.ReadInt(); } } }

写好之后重新编译dotnet build -c Release，重启服务端，然后在控制台或游戏内输入：

[add MyGlowingSword

如果一切正常，你会看到地上多了一把橙色的剑，玩家可以直接拾取。

这里有两个容易踩的坑：第一，类的命名空间不能和现有脚本冲突，否则编译器会报重复定义错误；第二，属性设置中有一些项是有前提条件的，比如先要设置Quality再设置Attributes，否则部分属性不会生效。

5.3 热重载与无需重启的更新方案

服务器不能老重启，玩家会跑光。ServUO支持C#脚本热重载，这意味着很多脚本改动可以在不重启服务端的情况下生效。

核心机制叫[reloadscripts和[compile命令。当你修改了某个脚本文件后，在服务端控制台输入[compile，它会重新编译所有脚本并替换到内存中。不过热度有限制：并非所有修改都能热更新成功。比如修改了事件注册、静态字段初始化逻辑，多半需要重启才能生效。

一个务实的做法是：小调整（数值、掉率、文案）用热重载；大改动（新系统、新任务流程）选一个凌晨低谷时段重启服务器。我的习惯是每周定一个固定维护时间，既保证更新效率，也减少对玩家体验的影响。

5.4 数据库选型：XML与MySQL之争

ServUO的存档默认基于二进制文件，但如果你希望做更复杂的数据统计和玩家管理，可以引入数据库插件。社区里常见方案有两种：XML存档和MySQL同步。

XML存档适合小规模服务器，数据量不大，读取方便，但高并发时容易有IO瓶颈。MySQL方案适合在线几百人以上的大服，可以配合Web网站做排行榜、公会管理和支付系统。

我个人的建议是：低于100人的服，用默认的二进制存档就够了，别自找麻烦；超过100人才考虑数据库方案。否则你还要处理MySQL安装、连接池调优、数据迁移等一系列问题，而这些对于游戏本身并没有直接提升。

6. 常见问题与排查技巧实录

6.1 编译报错怎么办

编译报错是最常见的入门障碍。这里总结几个典型场景：

• 如果你看到error CS0246: The type or namespace name 'Server' could not be found，这说明解决方案没有正确引用基础项目。先执行dotnet restore，再重新build。
• 如果你看到error CS0103: The name 'Target' does not exist in the current context，多半是脚本内部方法引用错了，检查当前类是否继承自正确基类。
• 如果你看到程序集版本冲突，比如Autofac版本不匹配，删除bin和obj目录，然后重新dotnet build。

很多编译问题本质上是对项目结构不熟悉导致的，不是代码逻辑错误。先看报错文件路径，判断是Scripts还是Server里的问题，再对症下药。

6.2 客户端连接不进服务器

这个问题排在所有UO架设问题里的第二位。常见原因有四个：

1. 客户端版本不匹配：ServUO默认支持特定客户端版本，如果客户端版本太老或太新，加密方式和版本号校验不通过，登录时直接断开。
2. 端口没通：确认服务器监听端口是2593，并且防火墙策略允许该端口入站。
3. 服务器没设置好公网IP：如果服务器在NAT后面，需要在Server.cfg中指定AdvertiseIP，让客户端拿到的IP是可公网访问的IP。
4. 客户端登录服务器地址填错：很多人把游戏服务器IP填成自己的公网IP，但客户端里真正要填的是真实可路由IP，区别在于是否做了端口映射。

如果远程玩家连接超时，先在他本机执行telnet 你的IP 2593，如果这个命令不报错，说明网络层是通的；如果超时，问题基本出在路由、防火墙或服务端监听地址。

6.3 世界存档常见损坏问题

存档损坏是运营中最怕的事故。如果你在服务器运行中发现日志出现Error loading save data，先不要慌，也不要立刻覆盖存档。

处理顺序应该是：

1. 找到Saves目录，查看最新的SaveData.bin，以及旁边的.bak备份文件。
2. 用备份文件恢复，将SaveData.bin.bak重命名为SaveData.bin。
3. 启动服务器，观察日志是否能正常加载世界数据。
4. 如果你有自动存档脚本，检查一下磁盘空间是否足够——很多存档损坏的根源其实是磁盘满了，文件写到一半被截断。

为了防止这种事再发生，强烈建议再加一层外部自动备份：用robocopy（Windows）或rsync（Linux）把Saves目录同步到另一块磁盘或远程服务器，频率和存档间隔保持一致即可。

6.4 典型问题速查表

下面整理一张我在日常运维中用得最多的排查表，按症状、可能原因、解决方案三列呈现：

这张表不能覆盖所有问题，但能解决80%的日常运维痛点。剩下的20%，基本只能在社区论坛搜或自己啃源码。

7. 服务器日常运营与社区维护经验

7.1 公告与活动管理

UO游戏内的公告和活动管理，不能靠GM手动刷屏。ServUO提供了一套广播系统，管理员可以在服务端控制台输入：

broadcast 欢迎来到服务器，请遵守规则。

这条指令会把消息推送给所有在线玩家，在客户端显示为黄色系统公告。如果想做定时公告，可以写一个简单的脚本，通过Timer定时器每隔N分钟发送一条消息。

大型活动则需要用到Engines/Events下面的事件框架。比如节日活动，ServUO默认带了一个WorldEventSpawner系统，你可以定义事件刷怪的时间窗口和怪物列表。这个系统的好处是：它能在不修改核心逻辑的情况下，实现"晚上8点全服刷一只巨型龙"这种效果。

7.2 玩家举报与反作弊

UO反作弊本质上是服务端脚本层面的博弈。因为客户端数据本来就完全由玩家掌控，服务端能做的，是对异常行为做检测和限制。

ServUO提供了一些基础反作弊钩子，比如对飞行穿墙、疯狂移动、修改内存这些行为会有一定的检测。实际运营中，更有用的是玩家举报机制。你可以在自定义脚本里实现一个[report命令，让玩家把疑似作弊的角色名和描述提交给管理员后台，这样GM查证时就有据可依。

防作弊要务实地看待：永远不可能100%拦截所有外挂，但足够规范的管理流程，加上快速的GM响应，能让绝大多数外挂滥用者失去兴趣。

7.3 数据备份与容灾规划

前面提过存档备份，但这里还想再强调一个实操要点：不要把备份文件和游戏存档放在同一块物理磁盘上。

我见过一个运营者，他把备份脚本放在服务器同目录下，用crontab定时把SaveData.bin复制成SaveData_copy.bin。然后有一天磁盘物理损坏了，副本也一起没了，整个服几年的数据全部蒸发。正确做法是至少把备份放到另一台机器，或者对象存储上。

另外建议定时做一次"数据可恢复性验证"，就是每个季度手动用备份文件恢复一台空服务器，确认存档能正常加载。不要等到事故发生时才发现备份文件早就损坏了。

8. 最后再聊点实在的

我自己折腾ServUO踩过最大的坑，就是一开始急着上线，跳过本地完整验证直接对外开放，结果玩家进来后各种怪癖bug频发，口碑直接崩了。后来学乖了，每次版本更新都会先在本地搭一个"预发布服"，自己用GM命令跑几条核心玩法链路，确认没问题再推送到正式服。这个习惯帮我避开了无数次事故。

还有个小技巧：在ServUO的Config/Game.cfg里有个DefaultSpeed参数，控制玩家基础移动速度。很多新人服主喜欢调高这个参数，觉得跑图快方便，但实际体验并不好，因为UO的PVP、技能释放、物品拾取全都依赖移动速度的计算，速度调得过高会让战斗节奏变得非常混乱。想加速，建议开传送门而不是调速度。

如果你是想长期运营一个社区服，我建议先把经济、PVP规则、阵营对战这三大块定下来，再去折腾新内容。ServUO给了你一个非常稳的地基，但怎么在上面盖楼，就看你自己了。

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