1. 项目概述为什么我们需要深入探讨C 3D绘图库在图形学、游戏开发、工业仿真、科学可视化这些硬核领域里摸爬滚打十几年我见过太多项目在技术选型上栽跟头。一个典型的场景是团队雄心勃勃地启动一个3D项目开发者兴冲冲地选了一个“名气最大”的库结果做到一半发现性能瓶颈无法突破或者某个关键特性不支持要么硬着头皮重构要么项目就此搁浅。这背后的核心痛点往往不是代码写得不好而是库没选对。“C 3D绘图技术实战主流库选型与应用场景解析”这个标题直指的就是这个最实际、也最容易让人纠结的问题。它不是一个泛泛而谈的“3D图形学入门”而是聚焦于“实战”和“选型”。这意味着我们要讨论的不是哪个库的API更优雅而是在真实的项目压力下面对不同的硬件平台、性能要求、功能需求和团队技能栈时如何做出最合适、最经济的选择。这背后涉及对图形管线原理的理解、对库架构设计的洞察以及对项目未来演进的预判。今天我就结合自己踩过的坑和成功的经验把这潭水彻底搅清给你一套可操作的选型方法论和避坑指南。2. 主流3D绘图库全景图从底层API到全功能引擎在深入选型之前我们必须先理清市面上有哪些“选手”以及它们各自的定位。C领域的3D绘图技术栈可以清晰地分为几个层次理解这个层次结构是正确选型的第一步。2.1 底层图形API一切的基石这是最接近硬件的层面直接与GPU驱动对话。选择这一层意味着你对性能和控制力有极致追求同时也愿意承担更多的开发复杂度。OpenGL老牌且经典的跨平台图形API。它的优势在于生态极其成熟资料、教程、社区支持海量从桌面到移动端OpenGL ES再到WebWebGL都有其身影。其即时模式Immediate Mode在旧版本中虽已淘汰但易于上手的特点曾教育了一代图形程序员。现代OpenGL3.3核心模式采用可编程管线功能强大。但它的缺点也很明显是一个巨大的状态机API设计较为陈旧错误排查困难一个glGetError可能对应N种问题且由Khronos组织维护驱动实现质量因厂商而异。VulkanKhronos推出的下一代底层API旨在提供更高的性能、更低的驱动开销和更好的多核CPU并行能力。它把更多的控制权和复杂性交给了开发者。你需要手动管理内存、同步、命令缓冲区和管线状态。这带来了巨大的性能提升潜力特别是对于CPU瓶颈严重的应用但代价是陡峭的学习曲线和巨大的样板代码量。它不适合快速原型开发更适合引擎开发者或对性能有严苛要求的AAA级游戏、专业仿真软件。DirectX 12微软推出的与Vulkan理念相似的底层API但仅限Windows和Xbox生态系统。它与Windows系统深度集成在自家平台上有最好的性能和工具链支持如PIX调试工具。如果你确定目标平台仅为Windows/XboxDirectX 12是一个极佳的选择。Metal苹果公司为iOS、macOS、iPadOS打造的底层图形和计算API。它同样提供了低开销、高控制力的特性并且与苹果的硬件和操作系统如Metal Performance Shaders深度优化。开发苹果生态独占应用Metal是唯一的一线选择。注意选择底层API本质上是在选择你的“战场”。OpenGL适合需要广泛跨平台且团队经验丰富的项目Vulkan/DirectX 12/Metal适合追求极致性能、控制力且有足够资源和专家团队的项目。对于大多数应用层项目不建议直接从这层开始。2.2 中层框架与抽象层平衡性能与效率直接使用底层API太痛苦中层框架应运而生。它们封装了底层API的复杂性提供了更友好的接口同时仍保留了较高的灵活性和不错的性能。bgfx一个杰出的“渲染抽象层”库。它的核心设计哲学是“通过一个统一的API在后台支持多种渲染后端包括OpenGL, Direct3D 9/11/12, Metal, Vulkan, WebGL等”。你写一份绘制代码bgfx帮你适配到不同平台。它自带简单的渲染状态管理、着色器编译链和纹理加载性能开销极小被许多商业游戏用作渲染中间件。适合需要发布到无数平台PC、主机、移动端的跨平台游戏或应用。Magnum一个现代的、模块化的C11/14图形中间件。它强调清晰的API设计、出色的文档和可扩展性。Magnum不仅封装了OpenGL/Vulkan还提供了丰富的工具如场景图、材质系统、音频、UI插件等。它更像一个“工具箱”你可以按需取用其中的模块。适合对代码质量有要求且希望深度定制渲染流程的团队。The Forge一个由Confetti原《星战前线》团队工程师创立维护的跨平台渲染框架。它同样抽象了多种底层APIDirectX 12, Vulkan, Metal, OpenGL并附带了高性能的渲染示例和工具。它的设计更贴近现代游戏引擎的需求适合作为自研引擎的起点。2.3 全功能游戏引擎开箱即用的解决方案如果你的目标是快速开发一个功能完整的3D应用或游戏而不是从头造轮子那么全功能引擎是最务实的选择。Unreal Engine (UE)行业标杆以顶尖的图形保真度和强大的蓝图可视化脚本系统闻名。其渲染器极其复杂和强大适合制作3A级画质的游戏、影视动画和高端仿真。UE是C编写的并允许深度C定制。但它的学习曲线陡峭二进制体积庞大对于小团队或移动端项目可能“杀鸡用牛刀”。Unity虽然主要使用C#但其底层渲染引擎和高性能计算部分如DOTS大量使用C。通过插件或底层接口C开发者可以深度介入。Unity的优势在于极其庞大的资产商店和开发者社区以及相对更轻量的入门门槛。适合需要快速迭代、依赖大量现有资源的项目。Godot开源、轻量且功能日益强大的引擎。其渲染器正在从自研的OpenGL后端逐步迁移到Vulkan。Godot的架构非常模块化全部代码C开源修改和扩展极其方便。对于喜欢开源、希望完全掌控代码且项目规模中等的团队Godot是一个极具吸引力的选择。O3DE (Open 3D Engine)由Linux基金会托管源自亚马逊的Lumberyard。它是一个模块化、开源、跨平台的AAA级引擎。其架构设计强调服务化和组件化适合大型、复杂的仿真和游戏项目。社区和生态仍在成长中但潜力巨大。3. 核心选型决策框架五维评估法知道了有哪些库下一步就是如何选择。我总结了一个“五维评估法”从五个关键维度系统性地评估候选库。3.1 维度一目标平台与部署环境这是最硬性的约束条件直接决定了一些选项的可行性。Windows桌面应用所有选项都开放。若追求极致性能且用户显卡较新可考虑DirectX 12或Vulkan。若需兼容老旧硬件集成显卡或老独显OpenGL 4.x或DirectX 11是更安全的选择。macOS/iOSMetal是苹果平台的“御用”API。跨平台方案中bgfx、Magnum、The Forge都支持Metal后端。OpenGL在macOS上已被标记为废弃新项目不应再基于其开发。Android/LinuxVulkan和OpenGL ES是主流。Vulkan在中高端设备上优势明显但OpenGL ES的兼容性更广。bgfx在这里是很好的抽象层。WebWebGL 2.0近似OpenGL ES 3.0是当前标准。未来WebGPU设计上接近Vulkan/Metal普及后将带来性能飞跃。如果目标包含Web需要评估库对WebGL/WebGPU的导出支持如使用Emscripten编译。游戏主机 (PlayStation, Xbox, Nintendo Switch)通常需要使用主机厂商提供的专用SDK或经过认证的中间件如Unreal, Unity。自研引擎接入需要深厚的经验和官方合作。实操心得永远不要假设“一个后端搞定所有”。在项目初期就用抽象层如bgfx或引擎可以极大降低后期移植的成本和风险。即使你暂时只做一个平台为未来留一扇门也是明智的。3.2 维度二项目类型与性能需求不同的项目对渲染的需求天差地别。数据可视化/科学仿真通常需要绘制大量简单的几何体点、线、三角形顶点数可能达到百万甚至千万级。瓶颈常在CPU提交指令的速度和GPU的顶点处理能力。Vulkan/DirectX 12的多线程命令录制能力能极大缓解CPU压力。如果数据量巨大还需考虑计算着色器进行预处理。CAD/CAM/工业设计强调精确的几何显示、复杂的布尔运算、大型装配体管理和高精度着色。对几何处理和光线投射用于选择、测量要求高。OpenGL的固定功能管线遗留特性如glPolygonOffset在处理深度冲突时有时很实用。但现代方案更倾向于在着色器中解决。游戏独立游戏/移动游戏更看重开发效率、包体大小和中低端设备兼容性。Unity或Godot是绝佳选择。如果自研OpenGL ES或Vulkan针对高端机搭配一个轻量框架是方向。AAA级游戏/大型MMO追求极致的画面表现和性能。通常会基于Unreal Engine进行深度定制或使用自研引擎底层多为DirectX 12/Vulkan。需要强大的工具链支持地形编辑器、材质编辑器、动画工具等。虚拟现实/增强现实对性能必须稳定90fps或更高、延迟Motion-to-Photon有极端要求。Vulkan/Metal的低延迟特性是关键。同时需要复杂的多视图渲染、畸变校正和时间扭曲技术。通常直接使用Unreal或Unity的XR框架它们已集成了这些优化。3.3 维度三团队技能与开发周期技术选型不能脱离团队实际。团队精通图形学有自研引擎经验可以直接挑战Vulkan/DirectX 12或使用bgfx/Magnum作为基础进行深度开发。你们有能力驾驭复杂性并享受完全的控制权。团队以业务逻辑开发为主图形学是辅助技能强烈建议选择高级引擎如Unity或Unreal。利用其可视化工具和丰富的资源快速实现想法避免在渲染细节上陷入泥潭。小团队或独立开发者追求快速原型Godot或Unity是首选。它们的入门快社区资源丰富能让小团队在有限时间内做出可演示的产品。开发周期紧张任何需要从底层搭建渲染管线的方案直接使用底层API或中层框架都会显著拉长开发时间。引擎能节省大量基础功能资源管理、物理、UI、音频的开发时间。3.4 维度四功能需求与生态整合你需要的不只是画三角形。物理模拟需要整合PhysX、Bullet、Havok等。引擎通常已内置。骨骼动画与状态机引擎提供成熟方案。自研需要实现蒙皮着色器、动画混合、状态树工作量巨大。粒子系统、后期处理引擎提供编辑器。自研需要实现GPU粒子、各种屏幕后处理效果Bloom, SSAO, Tonemapping。UI系统需要复杂的2D UI叠加在3D画面上。引擎的UI系统如Unreal的UMGUnity的uGUI是成熟解决方案。网络同步对于多人应用引擎的网络模块至关重要。资产管道如何导入、处理、优化美术资源模型、纹理、动画引擎有完整的工具链。评估表功能需求对照功能需求推荐方案理由与备注快速构建包含UI、音频、物理的完整游戏Unity / Unreal / Godot开箱即用生态完整避免重复造轮子。专注于特定领域的高性能渲染如地理信息系统、流体仿真Vulkan/DX12 自研 或 bgfx/Magnum需要完全控制渲染管线以实现特定优化通用引擎的渲染流程可能不适用或效率低。需要发布到超过5个不同的平台PC、移动、主机、Webbgfx 或 跨平台引擎Unity/Unrealbgfx的抽象层价值最大化引擎的“一键部署”能节省大量移植成本。项目是大型遗留C系统的3D可视化模块OpenGL 或 bgfx集成难度相对较低OpenGL的C风格API与遗留代码兼容性好。避免引入复杂的引擎运行时。研究和教学需要清晰理解图形管线Modern OpenGL 或 小型软渲染器从相对简单的OpenGL入手或自己实现一个CPU软渲染器是学习图形学原理的最佳途径。3.5 维度五长期维护与社区支持库不是一次性用品要看它未来5年的生命力。活跃度查看GitHub的提交频率、Issue的响应和关闭速度、最近版本的发布时间。一个多年未更新的库风险很高。社区规模Stack Overflow上的问题数量、Discord/Slack频道的活跃用户数、博客和教程的丰富程度。这直接决定了你遇到问题时能否快速找到答案。商业支持与许可Unreal Engine采用分成模式Unity有基于收入的许可。Godot、bgfx、Magnum是MIT等宽松许可证可免费商用。务必仔细阅读许可协议特别是关于专利、商标和源代码分发的条款。代码质量与文档好的文档能节省大量时间。浏览库的源代码看其结构是否清晰编码风格是否一致。这关系到未来你深度定制或排查bug的难度。4. 实战场景深度解析与库选型推荐让我们把理论应用到几个具体的、有代表性的场景中看看如何做出最终决策。4.1 场景一开发一款跨平台的移动端AR测量工具核心需求在手机摄像头画面中实时检测平面、放置虚拟物体并进行精确测量。需要高精度的空间计算、稳定的60fps渲染、低延迟。平台iOS (ARKit) 和 Android (ARCore)。关键挑战AR框架集成、跨平台渲染、性能功耗平衡。选型分析与决策AR框架绑定必须使用苹果的ARKit和谷歌的ARCore。它们提供了相机图像、位姿、平面检测等核心数据。渲染部分我们需要一个能同时在iOSMetal和AndroidOpenGL ES/Vulkan上高效运行的渲染层。自己维护两套原生渲染代码成本太高。方案对比Unity AR Foundation这是最主流、最快捷的方案。AR Foundation是Unity官方的跨平台AR抽象层完美对接ARKit和ARCore。Unity的渲染管线成熟性能优化工具如Profiler强大且有大量AR相关插件。可以快速搭建原型并专注于测量逻辑本身。Unreal Engine同样支持AR但移动端的生态和优化工具链略逊于Unity。对于这个工具类应用UE的庞大体积和更高的硬件要求可能成为负担。自研引擎bgfx 原生AR SDK理论上可行bgfx处理跨平台渲染。但你需要自己实现手势交互、UI、3D模型加载与动画、测量算法可视化等所有上层功能。开发周期极长且稳定性需要大量测试。最终推荐Unity with AR Foundation。理由最大化开发效率利用成熟生态稳定可靠能快速将产品推向市场验证。这是典型的“用合适的工具快速解决问题”的场景。4.2 场景二为大型工业软件如CAE仿真后处理开发新一代3D可视化模块核心需求可视化数千万甚至上亿的有限元网格、流场粒子、等值面。支持交互式剖切、缩放、旋转并实时着色如根据应力、温度值。要求渲染流畅内存管理高效。平台Windows为主部分客户需要Linux。关键挑战海量数据渲染、GPU内存管理、特定科学可视化算法如移动立方体法生成等值面。选型分析与决策数据特性数据是静态或准静态的但量极大。需要高效的顶点缓冲组织、可能用到实例化渲染或几何着色器。对交互实时性要求高。方案对比沿用旧版OpenGL如果旧模块基于固定管线OpenGL升级到Modern OpenGL核心模式是成本最低的路径。可以利用GPU缓冲对象VBO/IBO和着色器大幅提升性能。但多线程提交能力弱可能遇到CPU瓶颈。迁移至Vulkan能彻底解决CPU提交瓶颈通过多线程录制命令缓冲并精细控制内存应对海量数据优势明显。但重写成本极高且团队需要学习Vulkan。使用中层框架如MagnumMagnum提供了友好的C API来管理Vulkan/OpenGL资源并自带强大的场景图和可视化组件。它比纯Vulkan易用又比引擎灵活。你可以专注于实现科学可视化算法而不用操心窗口创建、上下文管理等杂事。集成全功能引擎过于笨重。工业软件有自己的UI框架如Qt、数据管理和业务流程。嵌入Unity或Unreal会导致进程膨胀且与现有架构整合困难。最终推荐Modern OpenGL (4.3) 或 Vulkan 自研/轻量框架。具体选择取决于性能压力和数据规模。如果数据量在百万级且交互复杂度一般Modern OpenGL是稳妥的升级选择。重点优化VBO数据布局、使用着色器进行GPU端计算如颜色映射。如果数据量达到千万级甚至亿级且需要复杂的交互操作如实时网格变形重计算Vulkan是长远投资。可以考虑采用Magnum作为框架降低初期开发难度。它可以让你用更现代的C方式工作同时为未来切换到纯Vulkan留有余地。4.3 场景三开发一个用于计算机图形学教学的可交互演示框架核心需求让学生能够编写代码实时看到基础图形算法如光栅化、着色模型、纹理映射、阴影算法的效果。框架需要简洁、直观不能有太多“黑盒”。平台Windows/macOS/Linux桌面端。关键挑战API简洁易懂、便于调试、跨平台、能逐步从“画三角形”扩展到复杂效果。选型分析与决策教学目的重点是理解概念而非工程优化。因此框架应该暴露足够的控制权同时隐藏平台相关的繁琐细节。方案对比直接使用OpenGL虽然直接但初始化窗口、管理上下文、处理输入等代码会分散学生对核心算法的注意力。且OpenGL的错误反馈不友好。使用GLFW Glad 自写薄封装GLFW处理窗口和输入Glad加载OpenGL函数指针。在此基础上自己写一些简单的辅助类来管理着色器、纹理和缓冲区。这是一个很好的平衡点既保持了透明性又减少了样板代码。使用Dear ImGui 后端Dear ImGui是一个出色的即时模式GUI库非常适合教学演示。学生可以轻松创建滑块、按钮来控制着色器参数实时观察效果。可以结合GLFW和OpenGL后端。使用游戏引擎过于“黑盒”学生无法看到底层绘制调用和状态变化失去了教学意义。最终推荐GLFW Glad 自研轻量封装 Dear ImGui。这是图形学教学领域的经典组合。你可以构建一个简单的“Application”基类封装好初始化、主循环、ImGui渲染。学生只需继承这个类重写render()函数在里面调用OpenGL命令和ImGui控件即可。代码清晰功能聚焦完美契合教学目标。5. 选型后的第一步环境搭建与“Hello Triangle”避坑指南假设我们为一个中等规模、需要跨平台和一定性能的桌面3D工具选择了Modern OpenGL (4.3) GLFW Glad的组合。这是很多项目的起点。让我们看看第一步怎么走以及会遇到哪些坑。5.1 环境配置与项目设置获取GLFW从官网下载预编译库或使用包管理器如vcpkg, conan。建议使用vcpkgvcpkg install glfw3。它会帮你处理依赖和编译选项。生成Glad访问Glad在线生成器。选择语言C/CSpecificationOpenGLAPI gl版本至少4.3Profile选Core。在Extensions里可以添加常用扩展如GL_ARB_bindless_texture。生成后下载zip包将include和src目录放入你的项目。CMake配置关键步骤cmake_minimum_required(VERSION 3.10) project(My3DApp) set(CMAKE_CXX_STANDARD 17) # 查找GLFW find_package(glfw3 REQUIRED) # 添加头文件路径 include_directories(${PROJECT_SOURCE_DIR}/third_party/glad/include) include_directories(${PROJECT_SOURCE_DIR}/third_party/glfw/include) # 如果手动放置 # 添加可执行文件 add_executable(My3DApp main.cpp glad.c) # 注意将glad.c加入编译 # 链接库 target_link_libraries(My3DApp glfw) # 链接GLFW # 在Windows上还需要链接OpenGL库 if (WIN32) target_link_libraries(My3DApp opengl32) endif()注意glad.c必须被编译进你的项目它包含了OpenGL函数的加载实现。忘记添加它会导致链接错误或运行时函数指针为空。5.2 编写“Hello Triangle”从VAO到着色器现代OpenGL的核心是顶点数组对象(VAO)、顶点缓冲对象(VBO)、着色器程序(Shader Program)和索引缓冲对象(IBO)。// main.cpp 核心片段 #include glad/glad.h #include GLFW/glfw3.h #include iostream // 顶点着色器源码 const char* vertexShaderSource R( #version 430 core layout (location 0) in vec3 aPos; void main() { gl_Position vec4(aPos.x, aPos.y, aPos.z, 1.0); } ); // 片段着色器源码 const char* fragmentShaderSource R( #version 430 core out vec4 FragColor; void main() { FragColor vec4(1.0f, 0.5f, 0.2f, 1.0f); // 橙色 } );接下来是初始化代码创建着色器、VBO、VAO并绑定数据。这个过程步骤固定但容易出错。5.3 常见问题与排查技巧实录即使是一个简单的三角形新手也常会遇到黑屏。以下是一个排查清单问题1窗口打开但一片漆黑。检查1GLFW上下文创建是否正确确保在glfwCreateWindow后、加载OpenGL函数前调用了glfwMakeContextCurrent(window)。检查2Glad初始化成功了吗在调用任何OpenGL函数前必须检查gladLoadGLLoader((GLADloadproc)glfwGetProcAddress)的返回值是否为真。检查3着色器编译链接成功了吗这是最常见的坑必须检查编译和链接状态。glCompileShader(vertexShader); GLint success; glGetShaderiv(vertexShader, GL_COMPILE_STATUS, success); if(!success) { char infoLog[512]; glGetShaderInfoLog(vertexShader, 512, NULL, infoLog); std::cerr 顶点着色器编译失败: infoLog std::endl; } // 对片段着色器和程序进行同样的检查检查4顶点数据格式对吗确保glVertexAttribPointer的参数与你的顶点数据布局匹配。例如如果你的位置是3个float那么参数应该是(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float), (void*)0)。检查5VAO绑定了吗现代OpenGL要求绘制前必须绑定VAO。在初始化时绑定并设置好顶点属性指针在渲染循环中绘制前再次绑定同一个VAO。问题2三角形颜色不对或显示异常。检查视口窗口大小改变时必须调用glViewport(0, 0, width, height)更新渲染尺寸。检查深度测试如果开启了深度测试(glEnable(GL_DEPTH_TEST))但没清除深度缓冲(glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT))或者三角形Z坐标不在[-1,1]范围内可能导致不显示。使用图形调试工具这是最重要的技巧不要只用printf。Windows使用RenderDoc。它可以捕获一帧的所有OpenGL调用查看纹理、缓冲区的数据单步执行着色器是图形调试的“核武器”。macOS/Linux可以使用CodeXL已不维护或Nsight GraphicsNVIDIA。对于OpenGLGLIntercept也是一个轻量级的调试工具。问题3程序崩溃或出现访问违例。检查函数指针确保所有OpenGL函数都是通过Glad加载的而不是直接声明。在Windows上不加载而直接调用glGenVertexArrays等新函数会导致崩溃。检查资源销毁顺序正确的销毁顺序是先删除具体的对象如VBO、着色器最后再删除共享的上下文或窗口。通常遵循“后申请的先释放”原则。6. 性能优化入门从“能画”到“画得好”当你的应用能正确渲染后下一步就是让它跑得更快、更流畅。优化是一个系统工程这里给出几个最立竿见影的切入点。6.1 减少CPU到GPU的通信开销这是早期优化收益最高的部分。批处理将多个使用相同着色器、纹理和渲染状态的物体合并到一个绘制调用中。避免在渲染循环中频繁切换着色器程序、绑定纹理和VAO。使用统一缓冲对象对于需要在着色器间共享或每帧更新的小块数据如相机矩阵、灯光参数使用glUniformBlock和UBO它比单个glUniform调用更高效。实例化渲染对于大量相同的物体如草地、树木、子弹使用glDrawArraysInstanced或glDrawElementsInstanced。将每个实例的变换数据放在一个单独的顶点属性或UBO中一次调用绘制全部。6.2 优化GPU端性能避免GPU管线停滞减少状态切换深度测试、混合、面剔除等状态的切换有开销。尽量对状态相同的物体进行连续绘制。小心glGet类函数如glGetError、glGetIntegerv。它们会强制GPU完成所有未完成的操作导致管线清空严重降低性能。只在调试时使用发布版本中应移除。着色器优化精度选择在片段着色器中对颜色等数据使用lowp或mediump精度可以提升移动端的性能。避免分支GPU擅长并行处理相同指令流if/else和循环可能导致性能波动。尽量使用纹理查找、mix函数等替代分支。减少纹理采样纹理采样是昂贵的操作。合并纹理纹理图集使用Mipmap并考虑在顶点着色器中采样然后插值到片段着色器如果变化平缓。6.3 内存与资源管理对象池对于频繁创建和销毁的对象如粒子、临时渲染目标使用对象池复用避免频繁申请释放内存。纹理与缓冲区管理使用纹理数组、纹理缓冲对象来组织资源。对于流式数据如每帧更新的顶点数据使用GL_DYNAMIC_DRAW提示和双缓冲或三缓冲技术来避免卡顿。我个人在优化一个大规模点云渲染器时最大的性能提升来自于将数十万个独立的glDrawArrays调用通过精心设计的数据结构合并成不到10个实例化绘制调用帧率从不足10fps直接提升到60fps以上。这告诉我在深入微观优化之前首先审视你的绘制调用次数和数据提交模式往往能发现最大的性能瓶颈。