企业官网建设流程全解析

前阵子做了一个基于 Unity 3D 和 C# 的飞机场漫游展馆系统，也就是把机场候机楼旁的航空文化展区做成一个可以在电脑上自由走动的三维虚拟展厅，参观者不用到现场，用鼠标和键盘就能逛完整个展馆，看飞机模型、点展板、听介绍。这个项目本身不算复杂，但涉及场景搭建、漫游控制、交互脚本、性能优化和打包发布一整条链路，踩过的坑也确实不少。这篇就完整复盘一遍我的实现思路和实际代码，重点讲清楚每一步为什么这么做，以及哪些地方最容易翻车，给正好要做 Unity 展馆、虚拟漫游这类项目的人一个可直接参考的底子。

1. 项目概述与设计思路拆解

1.1 项目定位与需求解析

先说清楚这个系统到底要解决什么问题。传统展馆受场地和开放时间限制，很多人到了机场只能隔着玻璃看几眼飞机，没法走近驾驶舱，也没法仔细读每一块展板背后的故事。这个漫游展馆系统的核心目标，就是把线下展厅的动线和内容搬到三维空间里，让使用者获得接近实地的沉浸感，同时用交互替代物理触摸。

需求拆开其实只有三条：能走、能看、能点。能走是指用户可以在地图范围内自由移动，视角要舒服；能看是场景里必须有足够还原度的飞机模型、展板和环境光，至少不能一眼看出是粗糙的 Demo；能点是点击展板或模型后弹出图文、音视频说明，这是展馆区别于普通游戏场景的关键功能。

围绕这三条，我把项目拆成四个模块：场景地形与美术资源、角色控制器与摄像机、交互检测与展示面板、性能与发布配置。这个拆分顺序也是开发顺序，先有场景，再让人动起来，随后做交互，最后才收拾性能和兼容性。很多人一上来就写交互代码，场景还是一片空白，结果后期反复返工。

1.2 为什么用 Unity 3D 而不是其他方案

同类方案其实不少，比如 Web 端的 Three.js 或纯 2D 的展厅 H5，甚至全景照片也能算一种漫游。但在这个项目里，Three.js 的自由度够，却需要我从底层处理碰撞、加载、材质管理，开发周期明显拉长；全景照片方案开发最快，但用户只能在固定点位旋转视角，无法真正走向展品，交互也只能限定在热区，沉浸感差太多。

Unity 3D 的优势在这类项目里非常明显：它有完整的地形系统、物理碰撞、UI 组件和成熟的资源商店生态，C# 脚本又能把展示逻辑和美术资源解耦，团队里只要有一个人熟悉 C#，整个交互层都能很快跑通。另外，Unity 的跨平台发布能力可以让我同一套代码同时出 Windows 桌面版和 Web 版，不需要做第二遍开发。这在展会、机场公共终端这类使用场景里很实用，有时候运营方只给了普通电脑，有时候需要放到触屏一体机上。

C# 作为主要开发语言还有一层好处：它和 UI 系统、序列化工具配合非常自然。比如展板信息我直接用[System.Serializable]定义数据类，Inspector 面板里就能拖配置，非程序员同事也能维护展品资料，不用每次改代码。

1.3 整体模块划分与场景规划

动手前我先画了一张展厅平面布局图，并决定主场景分为六个展区：入口大厅、民航发展史展区、飞机模型区、发动机剖面展示区、模拟驾驶体验区、文创休息区。入口大厅承担引导功能，模型区和驾驶区是交互重点，休息区用来看视频和浏览图文。动线设计成环形，用户从入口进入后沿顺时针走，不用走回头路。

对应到 Unity 的项目结构，我建了这些文件夹：

Assets/ Scenes/ // 主场景和测试场景 Scripts/ Player/ // 角色控制和摄像机 Interaction/ // 点击、射线检测、交互接口 UI/ // 展板面板、按钮逻辑 Data/ // 展品数据序列化与加载 Prefabs/ // 飞机模型、展板、可复用物体 Art/ // 纹理、材质、光照贴图 Resources/ // 动态加载的 Json 和说明文档

场景规划阶段最重要的一件事是确定实际比例尺。展馆长宽我按 80m × 50m 规划，飞机模型按 1:1 摆放但限定在独立区域，展厅通道保持在 3 米以上。否则用户经常撞墙卡视角，体验很糟糕。

2. 场景搭建与核心交互实现详解

2.1 机场展馆的三维场景布局与美术准备

场景布局不是贴完地砖就结束。我先把地面用 Plane 铺开，将材质换成淡灰色高光较弱的地面纹理，避免反光过强。展厅墙面用 Cube 拉伸组装，取消动态阴影以节省性能。天花板用反转法线的 Plane 或整块 Box 包围体，这个很多人会忽略，结果抬头就能看到空白天空盒，非常出戏。

飞机模型是这个项目的灵魂。大体两种来源：一种是从资源商店下载的高模客机，另一种是项目方自己建模的简易模型。我建议优先使用带 PBR 材质的模型，可以省去很多调光照的时间。对于没有贴图的模型，我会用 Unity 自带的 Standard Shader 配一层金属度和光滑度，也能出不错的效果。

灯光方面，我没用实时多光源，而是用一个主方向光加两个固定的补光，然后把所有静态物体设为Contribute GI，最后通过 Lightmap 烘焙。烘焙后的场景虽然没有动态光影，但胜在性能稳定，中低端电脑都能保持流畅。对展馆类项目来说，静态光照完全够用，因为绝大多数展品是静止不动的。

2.2 第一人称漫游控制与摄像机跟随

漫游控制我选择第一人称视角，而不是第三人称。原因是展馆里要看展板上的字，第一人称最直接，也更像真实逛展。项目里还留了一个按键切换到“自由视角模式”，方便布展调试，但发布版默认锁定第一人称。

核心运动脚本非常简单，我直接用CharacterController，不用 Rigidbody，因为这里不需要真实的物理弹跳，碰到展台时只要平滑阻挡就够了。代码如下：

using UnityEngine; [RequireComponent(typeof(CharacterController))] public class PlayerController : MonoBehaviour { public float moveSpeed = 4f; public float mouseSensitivity = 2f; public float gravity = -9.81f; private CharacterController controller; private Camera playerCamera; private float verticalVelocity; private float pitch; void Start() { controller = GetComponent<CharacterController>(); playerCamera = GetComponentInChildren<Camera>(); Cursor.lockState = CursorLockMode.Locked; } void Update() { HandleMouseLook(); HandleMove(); } void HandleMouseLook() { float mouseX = Input.GetAxis("Mouse X") * mouseSensitivity; float mouseY = Input.GetAxis("Mouse Y") * mouseSensitivity; transform.Rotate(Vector3.up * mouseX); pitch -= mouseY; pitch = Mathf.Clamp(pitch, -85f, 85f); playerCamera.transform.localRotation = Quaternion.Euler(pitch, 0, 0); } void HandleMove() { float horizontal = Input.GetAxis("Horizontal"); float vertical = Input.GetAxis("Vertical"); Vector3 move = transform.right * horizontal + transform.forward * vertical; if (controller.isGrounded) { verticalVelocity = -2f; if (Input.GetKey(KeyCode.Space)) verticalVelocity = Mathf.Sqrt(2f * 3f * -gravity); } else { verticalVelocity += gravity * Time.deltaTime; } move.y = verticalVelocity; controller.Move(move * moveSpeed * Time.deltaTime); } }

这里有两个很关键的避坑点。第一个是跳转和展馆场景不搭，默认功能我关掉了，避免有人乱跳打破沉浸感；我保留Space跳跃只是为了测试时能跳上展台看角度，正式发布前会删掉。第二个是鼠标旋转必须用localRotation而不是直接旋转 Camera 的父物体，否则视角会越转越歪。

展馆里我还加了两种移动辅助：传送式引导点和地图快速跳转。地图跳转用NavMesh做路径示意，真正的瞬移直接改controller.enabled = false后设置 position，再恢复启用，不然 CharacterController 会不让你移动。

2.3 C# 脚本框架与生命周期管理

这个项目不大，但脚本满天飞后一样会乱。我规定所有交互对象都实现一个IInteractable接口，由统一的交互管理器来调用，避免展板一个写法、模型一个写法。

public interface IInteractable { string DisplayName { get; } void OnInteract(); void OnHighlight(); void OnUnhighlight(); }

所有可交互物体都挂一个InteractableObject基类，内部实现接口的具体行为。比如ExhibitBoard继承它，点击后传入一个ExhibitData对象给 UI 管理器；AircraftModel继承它，点击后旋转模型一圈并弹出说明。

这个接口设计最大的好处是新增展品时不需要动任何交互主逻辑，只要挂脚本、填数据、实现接口，就能在场景里直接工作。后续项目方要求添加“触摸屏模式”时，我只要写一个TouchInput适配器，把触摸事件转成同一个射线检测流程即可。

生命周期管理上，我也补了OnDestroy和OnDisable的事件解绑约定。展板点击、UI 面板关闭这类常用的消息我直接用 C# 的event或UnityAction，但每次订阅都一定要对应注销，否则场景反复切换时会出现“越点越卡”甚至空引用崩溃。

3. 展品展示系统与交互细节优化

3.1 展板信息弹出与多级交互

展板是这个展馆的信息载体。我在每个展板前方放置一个名为InteractCollider的 Box Collider，当玩家的射线打到它时，触发高亮效果和可交互光标提示。关键代码是这样：

void Update() { if (!playerCamera) return; Ray ray = playerCamera.ViewportPointToRay(new Vector3(0.5f, 0.5f, 0)); RaycastHit hit; if (Physics.Raycast(ray, out hit, 8f, interactableMask)) { IInteractable interactable = hit.collider.GetComponent<IInteractable>(); if (interactable != null) { interactable.OnHighlight(); if (Input.GetMouseButtonDown(0)) interactable.OnInteract(); } } }

射线长度限制在 8 米。这个数值不是拍脑袋定的：机场展馆里展板离通道大概 2-4 米，8 米足够覆盖，又能避免隔着一个大厅误触到远处的展品。mask 用的是单独一层Interactable，不是 Default 层，防止地面和墙体也被射线响应干扰。

展示面板本身用 Unity UGUI 搭建。面板弹出后，我用一个半透明黑色背景遮罩挡住场景，防止用户一边点面板一边移动视角；按 Esc 或点击关闭按钮后，卸载面板并恢复鼠标控制。这期间一定要把Cursor.lockState先设为None，否则鼠标会继续被锁定，UI 按钮点了没反应。

3.2 飞机模型查看与多角度观察

为了让参观者能看清飞机模型的细节，我实现了两种展示模式：自动巡览和手动拖拽旋转。

自动巡览用DOTween插件做动画，点击模型后摄像机从当前位置平滑移动到模型前方的观察点位，再让模型缓慢旋转一圈。手动模式则允许用户按住鼠标左键左右拖动旋转模型，右键拖动切换观察角度。

DOTween 是我比较推荐引入的插件，它做 UI 动画和摄像机缓动比 Unity 自带的协程更可控。要注意的是，如果项目权限要求纯 C# 不想引第三方库，也可以用Vector3.SmoothDamp自己写缓动。我用过一段代码，效果也不会太差：

transform.position = Vector3.SmoothDamp( transform.position, targetPos, ref velocity, 0.4f );

旋转飞机模型时，必须在模型外层套一个空物体作为旋转轴。因为模型的自身坐标系和展台坐标不一定对齐，直接旋转模型会飘，用父物体旋转则始终绕展台中心转，用户体验稳定得多。

展品数据的维护我用的是 JSON 加ScriptableObject双轨制。每个展品在Resources/Data下放一份 JSON，包含标题、简介正文、图片路径、音频路径；如果团队里没有程序想快速改内容，我提供一个参数面板生成一个ExhibitConfig资产，两者序列化到同一个结构。读取使用Resources.Load<TextAsset>("Data/" + id)，方便但不建议放太多文件，否则会增加包体。

3.3 UI 布局与点击穿透问题的实际处理

展馆项目里的 UI 很容易出现“点按钮居然点到后面展板”的情况。原因是 UI 和场景射线使用的是同一个鼠标事件，而我没有拦截 UI 层的点击。

处理方式是给场景射线检测增加一个前置条件：只有当当前没有 UI 面板打开时才检测场景，或者使用EventSystem.current.IsPointerOverGameObject()判断鼠标是否在 UI 元素上。两种我都在用，但更常用的是前者，因为展馆内大部分时间面板是关闭的，性能更好。

if (EventSystem.current != null && EventSystem.current.IsPointerOverGameObject()) { return; // 鼠标在 UI 上，不执行 3D 射线检测 }

还有一个小细节是 Canvas 的Graphic Raycaster。如果 UI 面板的 Image 不小心把 Raycast Target 打开，透明区域也会阻挡点击，导致场景无法交互。我给所有纯装饰图片的 Raycast Target 都关了勾选，只保留按钮和必要背景。

4. 性能优化与打包发布的心得

4.1 Draw Call 与光照烘焙

展馆场景物体数量很多，如果不做优化，一次 Draw Call 可能直接冲到上千，帧率会卡得没法开。我主要做了这几件事：

一，所有静态物体勾选 Static，然后烘焙场景光照。烘焙需要提前设好光照参数，我用的是中等质量的光照贴图，分辨率 1024，配合压缩格式，既能看清展板阴影又不至于文件过大。

二，相同材质的物体尽可能合并网格。比如机场大厅的地砖、墙面、展台底座，我都用同一张纹理和同一个 Standard 材质。这一项操作让 Draw Call 从 300 多降到了 90 左右，效果立竿见影。

三，关闭多余的后处理效果。先说结论：Bloom 和景深很消耗性能，但展馆里又需要一点氛围，所以我只在入口大厅和模型展示区用了一个轻量 Bloom，其他区域不用。后处理组件开得多，中低端集成显卡根本带不动。

4.2 对象池与动态加载策略

展馆里有不少动态生成的内容，比如音视频播放、展板图片加载、模拟驾驶舱的仪表动画。如果每次进入展区都 Instantiate 和 Destroy，很容易造成 GC 峰值和卡顿。

我的做法是做一个简单的对象池，专门管理视频播放器和展牌图片对象。池子初始 5 个，不够时翻倍，回收时用SetActive(false)而不是直接销毁。对象池本身写起来不到 50 行，但确实救了测试时的多次切换卡顿问题。

动态加载方面，所有展品图片和介绍文档都放在Resources或Addressables。中小型项目用Resources.Load最省事，但要注意类型转换和异步加载。比如大尺寸展会图如果同步加载会造成明显掉帧，我统一用Resources.LoadAsync配合回调填充 UI 图片，虽然多几行代码，但体验改善很明确。

关于Mathf.PerlinNoise：我在地面材质上做了一层轻微的纹理扰动，用 Perlin Noise 生成展区边界的装饰地纹，这样视觉效果更自然，同时没有增加额外贴图。这个内置函数很适合做纯程序化纹理调整，网上很多代码都是直接float n = Mathf.PerlinNoise(x, y);，但实际用的时候记得乘上缩放因子，否则噪点太密像雪花屏。

4.3 打包发布与目标平台配置

这个系统最终要跑在两类环境里：Win10 以上的普通电脑和触屏一体机。所以我分别在 Standalone 和 WebGL 平台做了发布测试。

桌面端打包很直接，但有个坑：如果项目用了中文目录或带空格的路径，打包出来的程序有时会找不到资源。技术上不是绝对，但线上遇到过一次，排查很久才发现项目路径里有中文。建议项目根目录和导出路径全部用英文小写。

WebGL 端的坑更多。C# 的System.IO在 WebGL 里基本不可用，所以文本读取必须走Resources。另外 WebGL 不支持动态装配的Reflection，我的代码里没有涉及，但给后来者提个醒：如果用了反射相关的第三方库，WebGL 发布大概率要改。

内存管理上还要注意纹理格式。展馆里高清飞机贴图如果不压缩，WebGL 包体很容易超过 200MB，浏览器加载很慢。我统一把展板图片压到 2048 以下，模型贴图压缩到标准格式，最终 WebGL 包体控制在 80MB 左右，还能接受。

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

5.1 摄像机抖动与穿模问题

做漫游项目遇到最多的反馈就是“画面抖”。最常见原因是角色的眼球位置到摄像机之间发生微小碰撞，或者摄像机跟随代码用 LateUpdate 时和物理引擎产生相位差。

我的处理方法是把摄像机直接作为角色的子物体，位置固定在眼部高度（约 1.6 米），不单独写跟随逻辑。这样一个 Update 循环搞定所有控制，不会出现抖动。如果要做第三人称跟随，就要用 LateUpdate 并做插值，那不是本项目的重点。

穿模问题发生在用户靠近展台边缘时。CharacterController 会把玩家挡住，但摄像机可能已经探入展板内部。解决办法有几种：一是给所有展台 Collider 的边缘再向外扩一点；二是在摄像机前方加一个小的碰撞体，挤压时自动前移；我最终选择了前者，因为更稳定，不用额外写代码。

5.2 点击失效和 NullReferenceException

这个项目里最常遇到的代码错误就是NullReferenceException，十个里有八个和对象未初始化有关。比如面板还没创建就获取上面的文字组件、在Awake里找子物体但子物体还没激活等。

我统计排查方法有三步：

1. 打开 Console 窗口，定位报错脚本和行号；
2. 在报错前给变量加Debug.Log，确认是哪一步赋值失败；
3. 把所有GetComponent调用集中在Awake，所有Find调用放Start，避免执行顺序问题。

点击失效还有一个隐蔽原因：摄像机距离交互物体超过 8 米，或者interactableMask忘了加交互层。这种情况报错信息很少，我做了个调试快捷键 F2，开启高亮模式下射线命中的物体，直接看到射线的落点。

5.3 Unity 安装与试用版水印问题

正式开发前，项目组电脑有的装的是 Unity Hub 免费版，有的装的是带试用期水印的版本。试用版在预览窗口会有“Unity Personal”水印，但这里有个细节：如果团队已经符合 Unity Personal 的免费使用条件，安装时激活的是 Personal 许可证，不会生成水印；如果用的是试用版试用期，打包后也会带水印，这个是不能直接用于商业交付的。

我的建议是开发前所有人统一 Unity 版本，例如我用的 2021.3 LTS，并且都在同一个 Unity Hub 下激活同一个许可证。项目里的Packages/manifest.json也要通过集中管理，避免团队出现版本不一致引起的材质丢失或 API 差异。别小看这个问题，我见过一个同事用的 Unity 2020，另一个用的 2022，两个人合并项目后 prefab 直接崩了三天。

5.4 性能卡顿和帧率不稳的排查

帧率不稳定我一般先看两个指标：Draw Call 和 SetPass Call。Unity 的 Profiler 窗口能直接查看渲染耗时，如果发现BuildCommandBuffers或者Canvas.BuildBatch特别高，通常就是 UI 或者场景物体太多。

第二种常见卡顿是内存 GC 峰值。频繁创建string拼接或者List<T>扩容都会触发。我在这项目里统一用StringBuilder拼接展示文字，对象池缓存了复用的 UI 节点。

还有一个不太容易注意的地方是音频。如果音频文件不压缩且同时播放多段解说，也会造成 CPU 开销。我用了 AudioMixer，把背景音乐和解说分层，解说音量调整用衰减参数，画面完全不受音频影响。

5.5 常见问题速查表

6. 实操经验与项目扩展建议

6.1 一个值得养成的开发习惯：数据驱动展示

这个项目从第一天起我就坚持“展示内容不进代码”。所有展品资料都写成 JSON 或用 ScriptableObject 配置，程序里只关心字段名。好处是后期运营人员要改展板文字，只需要改 JSON 或 Inspector 面板，不需要重新编译发布。如果你能抽出时间，建议先把整个项目的交互对象抽象成配置驱动模式，哪怕前期麻烦一点，到后期一定会感激这个决定。

我刚写这个系统时图省事，把展板标题直接写在OnInteract()方法里，结果改了三次需求每次都要翻代码。痛过一次之后，我把所有展示内容集中到了数据层，同一套代码可以给不同的展馆项目复用。这也是为什么我强烈推荐ScriptableObject的原因：它结合 Unity 的序列化系统，配置起来比手写 Json 直观得多。

6.2 后续可以扩展的方向

这个系统做完了基础版，其实还有几个很值得做的扩展。第一是加 VR 模式，Unity 官方有 XR Interaction Toolkit，把第一人称控制改为手柄转向和瞬移即可；第二是做多人同屏，用Unity Transport同步每个玩家的位置，适合展馆开展线上直播活动；第三是给展品增加动画演示，比如把发动机剖面模板做成半透明逐渐展开。

如果需要做的是更大的场景，我推荐引入 Addressables 做资源热更新，这样后续新增展品不需要重新打包整个客户端，只需要更新资源组。中型项目前期不上 Addressables 问题不大，但项目方一旦要求“只改展品不动程序”，这套方案就是最优解。

最后再分享一个小技巧：每次发布前，我都会在场景里放一个隐藏的“巡游机位”，用 Timeline 录一段自动走完所有展区的镜头，然后在编辑器里直接播放检查碰撞和灯光。这个办法比手动跑一遍又快又全面，特别适合验收交底时给项目方演示完整动线。