企业官网建设流程全解析

做Unity这行几年下来，我最怕的不是某个API记不住，而是回头翻自己三年前写的笔记，发现根本找不到当时那条"摄像机跟随抖动的解决方案"到底存在哪个文件夹里。相信很多人跟我一样，笔记从最初的"新建文件夹(2)"一路演化成"Unity_学习_2019_不要删_重要"，最后连自己都不想打开。这篇内容就是把我这些年积累的Unity学习笔记，按一套可检索、可扩展的目录体系重新整理出来——它不只是一份索引，更是把散落在渲染、UI、平台发布、性能优化各个角落的知识点重新串成一条线。不管你是刚装好编辑器的新手，还是已经做过几个上线项目的开发者，这套目录结构和里面标注的实操要点，都能帮你少走弯路，尤其是那些官方文档不会告诉你的取舍细节。

1. 为什么Unity笔记需要一份目录，而不是一堆散文件

1.1 笔记失控的真实代价

我在带新人的时候发现一个规律：大多数人记笔记的方式，是按"遇到问题的时间顺序"来存的，而不是按"知识的结构关系"来存的。今天调了个阴影，新建一篇《阴影问题记录》；明天研究微信小游戏视频播放，再建一篇《视频播放踩坑》。半年之后，当你想系统性回顾"渲染相关"的知识时，发现这些笔记散落在十几个文件里，彼此之间没有任何横向联系，检索基本靠全文搜索碰运气。

这种散乱带来的直接损失，是知识的复用率极低。一个你明明解决过的问题，因为没有归类，下次遇到时又得从头查一遍，时间全浪费在重复劳动上。更深层的损失是，你无法看清自己在哪个方向上有系统性缺口。笔记目录其实就是你知识地图的投影——地图乱，说明你的认知也是碎片的。

提示：判断自己的笔记是否失控，有个简单标准——如果你的笔记里超过三次出现内容高度重复的条目，说明归类体系该重建了。

1.2 三层目录结构的设计逻辑

我这套目录采用的是"领域 → 模块 → 知识点"的三层结构，跟Unity自身的引擎架构大致对应。第一层是大的领域划分，比如引擎基础、渲染图形、UI交互、平台发布、性能优化、工程化；第二层是每个领域下的功能模块；第三层才是具体知识点的单篇笔记。

为什么按领域而不是按难度或时间分？因为实际工作中，问题几乎总是以"领域"的形态出现的——你调一个渲染问题，会在Shader、阴影、包围盒这几个知识点之间来回跳，它们应该待在同一个区域里，而不是被时间线打散。按领域归类，等于把关联性强的知识放在物理上相邻的位置，检索时的跳转成本最低。

另外一个设计原则是"预留空目录"。我一开始只建了四五类，后来又不断往回收拾，结果每次都要重新移动文件。后来学乖了，一开始就把已知会碰到的领域全部建出来，哪怕某些目录暂时是空的。空目录本身就是一种提醒——它告诉你这里还有一块知识没去碰。

2. 引擎基础与工程环境的笔记归档

2.1 安装、版本与项目骨架

引擎基础这块，我把"安装与版本管理"单独拉出来作为第一模块。别小看这块，Unity的版本迭代很快，不同版本对同一功能的支持差异能让你怀疑人生。我的笔记里专门有一节记录各版本的关键差异和升级踩过的坑，尤其是跨大版本升级时那些"能被编译但运行时行为变了"的隐性变更，这些在升级日志里往往只有一句话，但实际影响很大。

项目骨架结构也是新手最容易忽略的部分。我在笔记里固定记录了一套标准目录约定：资源放哪里、脚本怎么按模块拆文件夹、第三方插件单独隔离、场景文件命名规范。这套约定的价值在多人协作和后期维护时才真正显现——一个结构清晰的项目，接手的人半小时就能上手；一个乱堆的项目，光是找入口场景就得花半天。

关于下载和安装，我只记录官方渠道的获取方式，以及安装时组件勾选的经验：移动平台支持、WebGL支持这些模块体积很大，用不到的别装，装了会让编辑器启动变慢，也占硬盘。我试过全量安装，结果启动时间比精简安装慢了一截，后来只保留当前项目用得到的模块。

注意：升级引擎版本前，先备份整个工程目录，不要只依赖版本控制系统的历史记录，因为有些资源导入缓存不在版本管理范围内，回退时会出问题。

2.2 C#脚本与Unity特有机制

脚本这块的笔记我按"语言基础"和"引擎特有机制"分开记。语言基础指的是C#本身的语法、面向对象、委托事件、协程原理这些，这部分是通用的，我单独用一个模块，避免跟Unity特有的东西混在一起。很多人把C#基础和Unity API记在一块，结果复习语言时被引擎细节干扰，效率很低。

引擎特有机制才是重头戏，我记录的核心是脚本生命周期函数的执行顺序、特性（Attribute）的用法、宏定义的条件编译这几块。生命周期顺序看着简单，但实际调试时，Update和FixedUpdate的执行时机差异、Awake和Start的先后关系，经常是bug的根源。我在笔记里画了一张自己的时间轴，把这个顺序固化下来，遇到问题时直接对照。

宏定义这块特别实用。用条件编译可以在同一个工程里区分开发版和发布版，比如调试日志只在开发版里输出。我在笔记里记了几个常用宏的写法，以及怎么在编辑器里切换生效，这样打正式包时不用手动删代码。

知识点速查区我还会收录一些容易忘但有明确答案的概念，比如渲染器包围盒（Renderer.bounds）到底包不包含子物体、它和碰撞体的关系是什么。这类问题查一次忘一次，放进速查区，下次直接翻，不用重新搜。还有像Mathf.PerlinNoise这种噪声函数，我笔记里记的是它的输出范围、参数含义，以及在生成地形或纹理时怎么配合使用，这类工具函数属于"知道在哪查就行"的知识。

2.3 基础概念速查区的维护方法

速查区最忌讳的是把它写成流水账。我个人的做法是每条只保留"一句话结论 + 一个最小示例 + 一个常见误解"。比如包围盒那条，结论就是它描述的是渲染器的轴对齐包围盒，示例是获取中心点和尺寸的代码，常见误解是有人以为它随旋转实时紧贴——实际上它是轴对齐的，物体旋转后包围盒会变大而不是跟着转。

速查区我建议每季度清一次。过时的、已经内化成直觉的条目可以删掉，给新知识腾位置。笔记不是越多越好，能快速定位到有用信息才是目的。这个习惯我是从踩坑里养成的：曾经速查区堆了两百多条，结果找东西比重新搜还慢，反而成了负担。

3. 渲染、Shader与视觉表现的笔记体系

3.1 摄像机、分辨率与包围盒

渲染这块我第一个模块放的是摄像机，因为它是所有视觉呈现的入口。摄像机跟随是使用频率极高的功能，我的笔记里记了三种常见跟随方案：直接赋值位置、平滑插值、以及带前瞻的阻尼跟随，并标注了各自的适用场景。直接赋值简单但会抖，平滑插值稳但有延迟感，阻尼跟随在快速移动时手感最好但参数需要调。笔记里我把关键参数的含义和调参方向都写清楚了，而不是只丢一段代码。

分辨率设置是另一个高频问题。不同平台、不同屏幕比例下的适配方案，我按"固定高度""固定宽度""两者都固定并处理黑边"三种策略分别记录，还附上了横竖屏切换时要额外注意的点。这块的坑在于，编辑器里看着正常，真机上一测就错位，所以我的笔记强制要求每条分辨率相关的结论都标注"在哪个平台哪个设备上验证过"。

3.2 Shader与阴影问题

Shader的笔记我建议单独开一个大模块，因为它自成一个体系。入门阶段记录的是渲染管线的基本流程、顶点着色器和片元着色器的分工、常用内置变量的含义。进阶部分才开始记录自定义光照、边缘光、描边这类常见效果的实现思路。

阴影问题几乎是每个Unity开发者都会反复碰到的。我的笔记里把阴影问题拆成几类：阴影不显示、阴影闪烁、阴影边缘锯齿、以及阴影距离过远时突然消失。每一类都记录了可能的原因和排查顺序。比如阴影闪烁，常见原因是阴影偏移参数设置不当或者物体的包围盒过小导致被裁剪，排查时我会先看这几个参数，而不是盲目改阴影质量。这种"按现象归类、按顺序排查"的记录方式，比单纯记解决方案有用得多，因为现象是有限的，而具体的解决方案是无限的。

提示：阴影排查时，先关闭所有后处理再看基础阴影，能排除掉一半的干扰因素。

3.3 视觉细节技巧的沉淀

除了核心渲染，我还会专门留一块记那些"锦上添花"的视觉技巧，比如物体逐渐消失的脚本控制、对话过程中角色表情的变化驱动、以及天气效果的动态浮动。这些效果单看都不难，但组合起来能显著提升项目的完成度。

以物体逐渐消失为例，我的笔记里记了两种实现思路：一是改材质的透明度，二是改透明通道并配合淡出曲线。前者简单但受材质混合模式限制，后者更灵活但需要处理渲染顺序。笔记里我把两种方案的代价都写明了，方便按项目需求选。这类笔记的价值在于，它把你零散试出来的经验固化了，下次不用重新试错。

4. UI、交互与输入的笔记整理

4.1 UI显示隐藏三种方案的取舍

"UI显示隐藏到底该用哪种方式"这个问题，几乎每个Unity开发者都纠结过。我把SetActive、改localScale、以及把物体移出相机可视范围这三种方案单独做成一节对比笔记，因为这三种方式的性能代价和使用场景完全不同。

SetActive的优点是彻底，隐藏后相关组件不再执行，适合隐藏后短时间内不会再显示的元素；缺点是频繁切换会有开销，因为它涉及组件的启用停用和层级重建。改localScale的优点是切换极快，不涉及层级变化；缺点是物体还在场景里参与部分计算，而且如果有布局组件可能会出问题，边界情况多。移出相机范围则是折中方案，物体保持激活但不可见，适合需要保留状态的场景切换。

我的笔记里给了一个选择判断表：高频切换且需保留状态，用移出相机或缩放；低频切换且想释放开销，用SetActive。这种把决策逻辑写下来的方式，比单纯记三个API有用得多。

4.2 按钮点击范围与交互细节

按钮点不准是移动端项目的高频投诉点。我的笔记里记了一条：视觉上的按钮大小和实际可点击区域是两回事，实际响应区域由控件的射线检测区域决定。扩大点击范围的做法是在按钮边缘补一个透明的响应区域，或者调整控件的目标图形设置。笔记里特别强调，扩大范围时要考虑相邻按钮的间距，否则会误触。

交互这块我还记录了输入系统的两类方案：老输入系统和新输入系统，以及它们各自的适用场景。新输入系统更灵活，支持多设备重绑定，但对新手来说学习曲线陡。我的建议是按项目需求选，别为了"先进"而强行上新系统，简单项目用老的完全够。

4.3 Timeline、对话与表情驱动

Timeline是做过场动画和剧情演出的利器，我的笔记里把它单独作为一个模块。核心记录的是：轨道怎么组织、动画片段怎么衔接、怎么用Signal在特定时间点触发事件。Signal这块是很多人会漏掉的，其实它非常实用——可以在动画的某一帧精确触发一个逻辑，比如切换表情或播放音效。

对话变化的角色表情驱动，本质是"对话系统 + 表情状态机"的组合。我的笔记里记的思路是，表情切换不要硬编码在对话脚本里，而是让对话配置里带一个表情标识，由独立的表情管理器去响应。这样改对话内容时不用动逻辑代码，维护成本低很多。这种"配置与逻辑分离"的思路，我在很多模块的笔记里都反复强调，它是工程可维护性的关键。

5. 平台发布与跨端开发的笔记分区

5.1 微信小游戏打包与视频播放

微信小游戏打包是这两年问得最多的方向之一。我的笔记里把它作为独立的平台模块，记录打包流程、包体限制、以及常见的适配问题。包体控制是重中之重，小游戏对初始包体大小有硬性要求，所以资源分包、按需加载这些策略必须提前规划，不能等打包报错才想起来。

小游戏里的视频播放是个典型的"平台特例"。我的笔记里明确记了：不能直接照搬原生平台的视频播放方案，小游戏环境有自己的一套视频接口和限制，包括视频层级、播放格式、以及和UI的层级关系。这块的坑在于，编辑器里预览正常，真机小游戏里视频层级压不住UI，或者根本无法播放。所以我的笔记要求，平台特例类的知识点必须标注"验证环境"，避免误用。

5.2 Web部署到IIS与其他发布目标

发布到Web并部署到IIS这块，我的笔记记录的是构建产物的目录结构、服务端需要配置的响应类型、以及常见的加载失败原因。WebGL的坑集中在资源加载路径和压缩格式上，服务器如果没有正确配置响应头，构建出来的文件浏览器拒收，页面上就是白屏。我笔记里把必须配置的几个响应类型列成清单，部署时逐条核对。

其他发布目标我按平台分了组，移动端、桌面端、Web各一组，每组记录构建设置里的关键选项和平台特有的注意事项。这样分组的好处是，做新平台适配时，可以先看同组其他平台的经验，很多坑是相通的。

5.3 XR：Pico4与MR/VR切换

XR这块我单独开模块，记录Pico这类设备上的开发要点。核心经验是：设备上的性能和渲染限制比PC严格得多，帧率是硬指标，所以项目在PC上跑得再流畅，也不能想当然地认为设备上没问题。我的笔记里记录了针对移动XR设备的优化清单，以及双眼渲染带来的额外开销。

MR和VR之间的模式切换，我记录的是运行时的切换流程和需要注意的资源重建问题。这类内容比较新，我的笔记习惯是每次实践后立刻补录，因为资料少，靠记忆很容易丢细节。

6. 性能优化与工程化的笔记

6.1 优化清单与限定数据块大小

性能优化我建议单独建一个大模块，因为它横跨渲染、逻辑、资源各个方向。我的笔记里维护着一份"优化清单"，按优先级排列：先看DrawCall和批次，再看填充率，再看逻辑层的每帧计算。为什么要按这个顺序？因为渲染瓶颈在移动端通常比逻辑瓶颈更致命，先解决大头收益最高。

"限定数据块大小"这类优化点，指的是对批量处理的数据做分块，避免单帧处理量过大导致卡顿。我的笔记里记录的是分块的思路和阈值经验：比如资源加载不要一次性同步加载大批文件，而是拆成若干批分帧处理，避免主线程长时间阻塞。分块粒度需要根据实测调整，太细反而增加调度开销，太粗起不到作用。

提示：优化前后一定要用真实设备实测并记录帧率数据，不要凭感觉判断"变快了"，感觉极不可靠。

6.2 工程化：混淆与GameAssembly.dll

工程化模块记录的是发布环节的加固和构建机制。代码混淆是上线前的常规操作，我的笔记里记录了混淆的目