企业官网建设流程全解析

1. 从零搭一张 2D 地图：选型比手速更重要

以前在某团队做 2D 地图 demo，当时第一版做得特别顺手，两天时间把瓦片摆得整整齐齐，看起来还挺漂亮。结果真机一跑，卡成幻灯片，第二天同事改场景版本又冲突了一整天。后来才慢慢想明白：地图 demo 的核心难点从来不是“把瓦片一块块铺上去”，而是把地图当成数据工程来处理。瓦片怎么切、网格尺寸怎么换算、关卡配置怎么存储、本地化内容什么时候介入、性能优化从哪里入手，这些才真正决定了 demo 能不能顺利交付。

这篇内容是给正在做 Unity 2D 地图 demo 的人看的，不管你是刚接触 Tilemap 的初学者，还是已经写过一些玩法脚本、准备把地图做得更工程化的开发者，都能从中找到可以直接抄的配置方案和排坑经验。

1.1 先回答三个问题再开动

动手之前，我会先逼自己回答三个问题，这三个问题决定了后续所有技术选型。

第一个问题：这个 demo 到底要演示什么？如果是演示角色移动和战斗手感，地图规模通常控制在 50×50 格子以内，甚至不需要做程序化生成；如果是演示大地图探索，那就要考虑分块加载和运行时性能，Tilemap 的绘制方式也得额外规划。第二个问题：地图是静态的还是需要运行时变化？比如是否有破坏地形、季节变换、剧情切换地图。静态地图用 Tilemap 很舒服，但一旦涉及运行时动态替换瓦片，就要提前把地图数据独立出来，而不是把瓦片直接画死。第三个问题：目标平台是什么？PC、移动端还是 Web，直接影响纹理压缩格式、图集大小、批处理策略和物理参数设置。

这三个问题没想清楚就开干，后面大概率要返工。我见过好几个同事上来就铺地图，铺到一半发现网格尺寸和素材尺寸对不上，或者做程序化生成时才发现坐标换算一团糟，苦不堪言。

1.2 Tilemap 方案未必是唯一选择

把选择范围放高一点，2D 地图有几种常见做法：直接摆 Sprite、使用 Tilemap、运行时程序化创建物体、甚至用像素图做整图渲染。

做 demo 的大多数场景，Tilemap 都是最优解，因为它自带网格、调色板、规则瓦片和碰撞体支持，刷地图效率远高于一个个摆 Sprite。但也别盲从：如果你的“地图”只是一个 20×20 的小房间，每个物件都带独立行为，比如可交互的 NPC、可打开的箱子，那直接摆 Sprite 加组件反而更顺手。Tilemap 适合的是“大量长相重复、排列整齐、行为统一”的静态地形。

如果你要做的是一张无限大地图，运行时可扩展，那么纯 Tilemap 也有点吃力，常见的做法是程序化生成地图数据，再按区块写入 Tilemap，或者干脆做成 Chunk Sprite 渲染。我的建议是：demo 阶段优先用 Tilemap 打底，把地图数据抽象出来，这样后续就算换渲染方式，底层逻辑也不至于推翻。

1.3 版本和包版本选型

Unity 版本这里多说一句，推荐用当前能拿到的最稳定的 LTS 版本，不要用旧得离谱的版本，也不建议追最新 beta。2D 功能性包，特别是 Tilemap Editor、2D Sprite、2D PSD Importer 这些，最好在 Package Manager 里统一确认版本。很多地图相关的疑难杂症，其实不是代码问题，而是内置包版本和 Unity 版本不匹配导致的。

另外把脚本运行方式保持默认，不要随便改 Scripting Backend，demo 阶段以稳定为主。如果你打算后续做 Web 或移动端，再提前切换 IL2CPP 测试一遍。

2. 地图编辑：从空场景到能跑的地图

接下来开始落地操作。这一部分我按实际编辑顺序来写，从创建场景、切割瓦片、铺设地图，到添加碰撞体和排序设置，每一步都附上配置理由和容易踩的坑。

2.1 创建 Grid 和 Tilemap 的分层思路

新建场景后，第一步不是创建 Tilemap，而是先创建一个 Grid 物体。这是 Tilemap 世界里的核心容器，它决定了所有瓦片的坐标基准。在 Grid 下可以挂多个 Tilemap，像是“地面层”、“障碍层”、“装饰层”，它们共享同一个 Grid，坐标体系就统一了。

我不知道有多少人一开始直接创建单个 Tilemap 就开铺，最后发现要加碰撞层，又在场景里东拼西凑。正确做法是在 Grid 下面分别建几个 Tilemap GameObject，再给每个 Tilemap 设置好 Sorting Layer。我常用的分层包括：地面层负责土地和道路，装饰层负责花草、石板纹样，障碍层负责不能行走的墙，交互层放可触发物件。

Sorting Layer 的规则是：先画地面层，再画装饰层，最后画障碍层和角色。这样角色站在墙后面时，遮挡关系不容易乱。如果你要做的是俯视角 2D RPG 类型，这个顺序基本够用。

2.2 瓦片切割、规则瓦片与调色板

素材方面，最常见的坑是 PPU 和 Grid 尺寸对不上。假如你的瓦片素材是 32×32 像素，在纹理导入面板里把 PPU 设置为 32，这样一个瓦片在场景里就是 1×1 单位；如果 PPU 设成 16，一个瓦片就是 2×2 单位，Grid Cell Size 却还是 1×1，铺上去就全乱了。所以拿到素材的第一件事，先统一像素尺寸与 PPU，记住这组数。

然后是切割瓦片：把整张 Sprite Sheet 导入后，打开 Sprite Editor，选择 Slice，按 Cell Size 切好。切割后可以在 Tile Palette 面板里创建调色板，把切好的瓦片拖进去，之后就能像画笔一样刷地图了。

规则瓦片建议一定要用。它做的事情是：根据相邻瓦片自动选择正确的外观。举个例子，你刷一堵墙，如果手动选瓦片，边缘和内墙的图要根据邻接关系来回切换，非常崩溃。规则瓦片配好规则后，按住左键刷一大片，自动把转角、边缘、中心都匹配好。写规则时有一点要注意，不同平台的 Tilemap 包版本对“规则图标”的显示方式有差异，但逻辑一致：把每个方向是否存在瓦片勾选出来就行。

2.3 碰撞体配置：尽量一个 Collider 解决

2D 地图的碰撞问题，处理得好不好直接决定性能。很多新手会把 Tilemap Collider 2D 直接加到障碍层上，然后发现角色移动时卡顿，物理开销飙升。原因在于每个瓦片都会生成一个独立碰撞体，几十个瓦片就多几十个碰撞体，物理引擎要逐个检测。

我的做法是在障碍层上加 Tilemap Collider 2D，再在该 Tilemap 的子物体上挂 Composite Collider 2D，同时把 Tilemap Collider 的 Used By Composite 打勾。Composite Collider 会把所有瓦片合并成一个整体碰撞轮廓，物理性能好得多。Geometry Type 我建议用 Polygons，相比 Outlines，生成的碰撞形状更贴合瓦片边缘，角色路过时不容易卡到锯齿。

这里有个隐藏细节：Composite Collider 会把同一 Tilemap 里所有瓦片都合并，所以同一张 Tilemap 上不要既放挡住角色的墙，又放不产生碰撞的地板装饰。否则地板装饰也会被合并进碰撞体，造成意外的阻挡。消极做法是给地板装饰单独一层 Tilemap，不加 Collider；积极做法是直接让装饰层不带碰撞组件。

2.4 排序和遮挡：做好一层少烦三天

2D 游戏的排序看着简单，做 demo 时最容易被忽略。Tilemap 本身有 Sorting Layer 和 Order in Layer，这决定了地图各层之间的前后关系。角色踩过草地、钻进树丛、走到建筑后面，这些遮挡需求靠排序顺序就能完成大半。

如果你做的是类似斜视角或者透视遮挡关系复杂的地图，可以尝试开启 Y Sort。Y Sort 的机制是物体按照自身 Y 坐标进行排序，Y 越小越靠后。比如一个角色走到大树下方时，他的 Y 坐标变大，就会排在大树前面，形成被遮挡或遮住树的效果。但 Y Sort 在大型地图上容易出现“闪烁”和排序抖动，建议只在局部区域复杂时启用，普通 demo 用一个统一的 Sorting Layer 方案就够了。

3. 地图数据、本地化与程序化生成的联动

地图铺完，看起来像样了，但真正让 demo 开始“活起来”的是数据和逻辑部分。很多人在这一步才开始手忙脚乱，因为纯手工摆出来的地图无法被代码理解，也无法被循环利用。

3.1 把地图抽象成数据

我最推荐的做法是：不直接依赖场景里的瓦片，而是为地图单独建立一个数据层。你可以用一个二维数组描述每一个格子是什么，比如 0 代表空地，1 代表墙，2 代表水，3 代表出生点。这个数组可以存在 JSON、ScriptableObject 或者一个简单的文本文件里。

为什么这么折腾？因为你会遇到这类情况：策划想调关卡布局，如果直接改场景瓦片，程序、美术、策划三拨人容易互相覆盖；但改一个地图数据文件，谁都能独立操作。而且做程序化生成、地图切换、存档系统的时候，数据层会让你舒服很多。

坐标换算也是重点。Tilemap 提供了两个关键接口：CellToWorld 和 WorldToCell。前者把格子坐标换算成世界坐标，后者把鼠标点击的世界坐标换算成格子坐标。写交互逻辑时，我几乎每天用这两个方法。举个例子，玩家点击屏幕，你拿到的是世界坐标，想定位他选中了地图上哪个格子，就调 WorldToCell；然后你要在这个格子上放一个物件，再调 CellToWorld 拿到准确的摆放位置。自己做的话很容易用像素坐标硬算，其实引擎已经帮你封装好了。

3.2 地图配置的本地化处理

很多团队理解的本地化就是把 UI 文本换成多语言，实际上地图里的本地化同样重要。地图名称、区域名称、NPC 对话、任务描述，甚至地图里的告示牌文字，都要考虑多语言问题。如果这些文本硬编码在场景的 TextMeshPro 组件里，等需求出来再翻多语言，你会想把地图重新做一遍。

我的做法是给地图里的每个可读元素绑定一个文本 ID。比如地图名字存 key 为 map_name，区域提示存 key 为 zone_warning。显示时根据当前语言去加载对应的字符串表。这样地图文件里永远只有 ID，不包含具体语言，语言表单独管理，翻译同学只需要维护一个表格，不用碰场景。

还要注意字体问题。中文、日文、韩文这类字符集比较大，默认字体经常缺字，显示成方块。demo 阶段建议预先准备一个支持目标语言字符集的动态字体，而不是嵌死一种字体资产。如果地图里还有特殊字符，比如坐标符号、箭头上标、单位缩写，也需要额外测试一遍。

3.3 程序化生成：随机 + 种子控制

如果你需要随机地图，又想把结构控制在合理范围内，我推荐“半程序化”思路：先程序化生成基本格局，再允许策划手动微调。比如说要生成一个房间加走廊的地下城，程序负责保证所有房间都是封闭连通的空间，美术和策划再在特定位置放上事件触发点、宝箱和敌人。

生成算法的经典套路是 BSP 分割或者随机房间连接。BSP 的做法是把地图区域不断二分，生成若干矩形房间，再用走廊连接相邻节点。这算法实现起来不复杂，却能保证地图不会乱成一团。做这类生成时，种子概念要单独处理：给地图一个 seed，通过 Random.InitState(seed) 再生成，这样同一种子必定生成同一张地图，方便测试复现。如果忘记设置种子，生成结果每次都不一样，排查 Bug 会非常痛苦。

实际写代码时，一点性能经验分享：程序化生成地图千万不要一个格子一个格子调用 SetTile，尤其是几百个格子的时候，不仅写起来啰嗦，运行效率也低。正确做法是准备一个 TileBase 数组，把所有格子的瓦片填好，然后一次性调用 SetTiles。这个方法一次调用就能替换整块区域，内部批量处理，效率提升非常明显。

4. 性能优化：2D 地图卡顿怎么治

把地图铺完、逻辑接好，就要面对性能问题了。卡顿的源头不外乎这几类：纹理和图集不合理、重建批次太多、物理碰撞体庞大、运行时动态操作过于频繁。我按优先级逐条来说。

4.1 纹理、图集和导入设置

没有做图集的地图，第一眼就输了一半。瓦片素材数量往往很多，如果不打包进图集，GPU 会切换纹理贴图，Draw Call 会飙高。2D 项目里最常用的办法是用 Sprite Atlas 把瓦片、装饰、角色等一系列 Sprite 打包成一张大纹理。重点在于：同一帧渲染的 Sprite 尽量都来自同一张图集，材质也尽量共用。

导入设置方面，我通常把瓦片纹理的 Generate Mip Maps 关掉。2D 场景大多不会用到 mipmap，反而浪费内存。Filter Mode 我习惯设置成 Point，尤其是像素风题材，可以避免瓦片出现模糊边缘和缝隙。如果你发现地图瓦片之间有细细的缝，先检查 Filter Mode 是不是 Bilinear，再检查纹理的 Wrap Mode 是否设置为 Clamp，这两点能解决绝大多数缝隙问题。

4.2 Draw Call 和批处理观察方法

判断性能瓶颈，不要靠感觉。打开 Window > Analysis > Frame Debugger，可以看到每一帧的 Draw Call 列表和批次情况。Tilemap 的优势在于相邻瓦片会被引擎合并渲染，所以静态地形通常不会产生特别夸张的 Draw Call。但如果你在地图上放了成百上千个独立 Sprite，比如每一棵树都是单独 SpriteRenderer，Draw Call 就会飙高。

这时候要么把大量静态物件合并成一张图集，要么放进 Tilemap，要么使用 Sprite Renderer 的合批。动态批处理对 2D Sprite 有 CPU 开销，如果同屏几百个 Sprite，即使合批也未必划算。经验判断是：静态优先 Tilemap，动态对象用对象池，能用一层空图集解决的就不新增材质。

4.3 运行时操作的性能陷阱

我见过不少 demo，地图本身不卡，但某一瞬间突然卡一下，原因是代码里做了大量逐瓦片操作。比如循环里逐个判断当前格子类型，每个格子调一次坐标转换和相关查询。这类操作集中在同一个卡点上，就会造成瞬时冻结。

解决办法的核心是减少重复计算：把常用格子的类型信息预先存在字典或 HashSet 里，而不是运行时反复调用 Tilemap 的查询方法。比如你要判断某个步数范围内是否存在障碍，可以一次性把这个区域的瓦片数据取出存成数组，之后所有逻辑只在数组上计算，只在视觉变化时更新 Tilemap。移动端上这条经验效果立竿见影。

对象池也别忘了。地图上的交互物、拾取物、敌人弹出的伤害数字，如果频繁创建和销毁 GameObject，GC 压力会在真机上放大，进而出现随机卡顿。建一个通用对象池，初始化时批量生成，用的时候激活，不用时回收，能省掉大量 GC。

4.4 物理性能调整

2D 地图场景里，物理开销主要来自碰撞体和刚体数量。前面说的 Composite Collider 已经帮我们把静态瓦片的碰撞体合并，这是最重要的一步。其次是角色和敌人身上的 Rigidbody2D 数量，尽量控制在几十个以内。demo 阶段如果敌人数量需要很多，建议只给玩家和少数高优先级角色真实的刚体物理，其余用简单的移动加检测脚本代替。

你也可以在 Physics2D 设置里调整 Velocity Threshold 之类参数，让刚体更容易进入睡眠状态。睡眠的刚体基本不占 CPU，这是免费的性能。还有一点常被忽略：不要在地图上堆大量触发器。如果你踩进一个草丛就触发一个 Trigger，堆了几百个触发器的话，物理检测依然有成本。尽量把触发器做成网格化判断，或者在合适时机开关触发器组件。

5. 版本控制：地图项目里最容易翻车的环节

地图 demo 做到中后期，最大痛点永远是协作者之间的文件冲突。场景文件是纯 YAML 文本，只要两个人同时改同一个场景，Git 合并的时候几乎必冲突。我的经验是：地图项目必须从一开始就走版本控制细化，而不是等冲突发生了再临时补救。

5.1 .gitignore 和 meta 文件

Unity 项目提交 Git 之前，先写好 .gitignore。需要忽略的包括 Library、Temp、Obj、Build、UserSettings、Logs 以及所有 .csproj、.sln 文件。这些目录和文件都是本地生成内容，提交了只会增加冲突概率，没有任何意义。

同时要提交所有 .meta 文件。Unity 用 meta 文件记录资源 GUID，场景和预制体都是靠 GUID 引用资源的。如果 meta 文件缺失或者被 Git 忽略，同事拉下来代码后，引用会全部断掉，表现在场景里就是一堆 Missing。正确做法是让 meta 文件纳入版本控制，不要动它们，不要“清理”这些文件。

5.2 场景合并冲突的实用解法

场景冲突的根源是多人同时编辑同一个场景文件。最有效的逃避方式是：一个场景只允许一个人同时改。听起来像废话，但很多团队做不到，原因是没有把工作拆细。比较好的做法是：场景里只放位置引用，所有复杂逻辑放在 Prefab 里，多人各自编辑自己的 Prefab，然后在场景里摆好。

如果你必须处理场景合并冲突，把 Unity 的 Asset Serialization 设置为 Force Text。这样场景文件至少是文本格式，有清晰的 diff 基础。你可以在 Project Settings > Editor > Asset Serialization 里设置。改成文本后，场景里新增一个物体，diff 会显示多了一段 YAML 节点，手工解决的可能性高一些；如果保持二进制，基本没法合并。

不过还是要提醒一句：场景冲突不能靠手工硬合并，最稳定的流程是让改动最小化。比如做了某个 NPC 的功能，就只提交那个 NPC 相关的 Prefab 修改，场景新增一行实例即可。让场景的 diff 尽量小，才能避免无谓的冲突。

5.3 分支和提交习惯

地图开发阶段，我习惯分成三类分支：main 分支始终保持可运行；feature 分支做具体功能或地图区域；release 分支用来打包测试。main 分支不要直接提交未验证的改动，所有合并经过代码审查。demo 阶段团队不大，也要坚持这个习惯，不然某个无关紧要的改动把整个启动流程弄崩，所有人都会停下等你修。

提交信息也尽量写清楚“改了什么、为什么改”，不要用“update”这类含糊信息。回头排查问题时，清晰的提交历史能大幅缩短定位时间。我在某次调试地图寻路问题时，就是靠提交历史定位到某位同事把地图数据文件里的行分隔符改了，导致解析逻辑异常，前后花了不到十分钟。

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

下面整理一份我在各种项目里见过的高频问题速查表，都是实际发生过的场景，可以直接对照排查。

格式方面再强调一个：Tilemap 的瓦片坐标和逻辑网格坐标要统一。只要分层或者模块增多，很容易出现“A 模块按格子坐标处理，B 模块按世界坐标处理”的错位问题。我建议所有逻辑都采用格子坐标，只在最终渲染和输入转换时使用世界坐标。这个约定最好从地图数据层的设计阶段就定下来，后面所有脚本都遵循，能避免大量莫名其妙的偏移 Bug。

7. 几个我坚持的地图 demo 心得

做地图 demo 做到最后，其实拼的不是谁铺瓦片铺得快，而是谁能在问题出现之前就预防。我个人比较喜欢先花半小时把工程目录和命名规范定好：Scenes 里放根场景，Art 目录按 Tilemap、UI、角色分开，Scripts 里按地图数据、生成、交互、工具分类。命名时前缀加上模块名，比如 MapData_StartZone，一看就知道归属，搜索也方便。

另外，地图 demo 的构建速度一定要在自己可控范围内。如果每改一行代码，构建要五分钟，团队所有人的效率都会被拖垮。Performance 优化不只是运行时表现，也包括构建时间和热重载速度。很多时候，目录里有大量大体积资源没有及时筛选，构建就慢下来了。地图展示用的临时纹理、未用到的测试场景，能清就清，能压缩就压缩。

最后再分享一个小技巧：地图 demo 完成后，别急着删临时测试脚本和调试代码。留一个“地图 Debug 视图”的开关，在 Editor 里可以显示格子坐标、阻挡区域、生成点和连接关系。这个在后续扩展玩法、调平衡、排查寻路问题时非常管用。我吃了好几次亏，后来直接把调试开关做成代码里一个静态标志，生产环境关闭，开发环境打开，谁用谁舒服。