Unity3d游戏开发用哪个语言？C#、C++、Lua与原生插件选型全解析

发布时间：2026/9/17 1:33:23

1. 先别急着选语言Unity里其实有三层语言在同时干活上周有个做美术转程序的朋友问我Unity3d游戏开发用哪个语言更好是不是C性能最强就该上C。这个问题我这些年被问过不下二十次每次我都得先反问一句你说的是哪一层因为Unity3d游戏开发这件事语言从来不是单选题一个正常上线的项目里至少有三层不同性质的语言在同时跑混在一起谈哪个更好结论一定是错的。第一层是脚本层也就是你每天在Assets目录下敲的那些文件负责游戏逻辑、UI、状态机、数值计算。第二层是引擎层Unity自己的核心是用C写的渲染管线、物理、音频、资源加载都在这一层你摸不到源码但它的设计约束会直接影响你脚本能写多快。第三层是数据与资源层包括Shader语言、配置文件、序列化格式、本地化表甚至SQLite这种嵌入式数据库。这三层的语言选择逻辑完全不同脚本层追求的是迭代速度引擎层追求的是执行效率与可控性数据层追求的是可读性与可维护性。所以Unity3d用哪个语言这个问题的正确问法应该是在Unity3d游戏开发的哪一层用哪种语言投入产出比最高。我先给个直接结论方便你带着答案往下看脚本层用C#别犹豫引擎层你碰不到也不需要碰只有当你确实撞上性能天花板或者需要对接第三方原生库时才考虑用C写原生插件。至于C语言它在Unity项目里的位置比你想的要边缘得多后面我会详细说清楚为什么。1.1 脚本层、引擎层、数据层各自在说什么话把这三层拆开看会清晰很多。脚本层是Unity暴露给你的接口层所有MonoBehaviour的生命周期函数、协程、事件系统、UI系统都在这层官方唯一完整支持的语言就是C#。引擎层是Unity的C内核你调用Transform.position、Rigidbody.AddForce背后都是一次从托管代码到原生代码的跨界调用在IL2CPP下称为P/Invoke式的内部调用这个跨界本身是有成本的很多人抱怨Unity性能不行其实抱怨的是自己写了太多高频跨界调用。数据层的语言就更杂了。Shader你得用HLSL风格的ShaderLab做GPU计算要用Compute Shader配置表可能是JSON、CSV、YAML或者Unity自己的ScriptableObject聊天记录、背包数据这类需要查询的很多人会塞一个SQLite进去那就得写SQL。我见过一个项目把技能配置直接写成Lua表策划改数值不用重新打包这个思路本身没错但和Unity3d游戏开发用哪个语言这个问题是两码事。真正需要你做决策的其实只有脚本层。而脚本层的答案在2018年之后就已经没有悬念了。1.2 UnityScript和Boo的退场说明了一件事老一点的开发者应该记得Unity早期同时支持三种脚本语言C#、UnityScript一个JavaScript风格的方言、BooPython风格。当年不少教程用UnityScript写因为语法看起来亲切function Update() {}这种写法对新手门槛低。但从Unity 2017.3开始官方就把UnityScript和Boo标记为废弃2018.3之后新建项目里连创建这两种脚本的选项都没了。为什么不是因为C#更好看而是因为维护三套脚本绑定层意味着三倍的语言特性跟进成本。Unity每加一个新特性比如async/await支持、Span、新的序列化机制都要在三种语言里各实现一遍而社区生态——插件、教程、第三方库——也会被撕成三份。官方最终选择了C#因为C#有微软持续投入的Roslyn编译器、有完整的.NET生态、有静态类型带来的IDE智能提示质量。这件事对今天的新手有很强的参考价值在一个技术栈里语言选择往往不是由性能决定的而是由生态和长期维护成本决定的。你顺着主流走遇到问题能搜到答案你逆着主流走遇到问题只能自己啃源码。做商业项目这个差异能决定上线时间。2. C#凭什么成为Unity的主力语言我见过不少人一听到游戏开发就条件反射想到C觉得托管语言性能不行不够底层。这个印象在十年前或许还有点道理但放在今天的Unity3d游戏开发场景里基本属于过时认知。C#能坐稳主力位置靠的不是性能而是开发效率与性能之间的平衡点抓得准再加上几个关键工具把它的性能短板补上了。2.1 托管运行时带来的开发效率红利C#在Unity里跑在Mono或IL2CPP的托管运行时上最直接的好处是自动内存管理。你不用手动new/delete不用担心悬空指针不用为了一个忘记释放的缓冲区排查三天。对一个需要快速迭代玩法的游戏项目来说这个红利非常实在原型阶段你可能一天要重构三次数据结构手动内存管理会直接把你的精力耗光。第二个红利是反射与序列化生态。Unity的Inspector面板能把字段暴露出来给策划调靠的就是反射JSON序列化、ScriptableObject、AssetBundle的依赖分析也全都建立在.NET的元数据系统上。你要是用C写逻辑想实现一套改字段不用重新编译的编辑器体验工作量会大到不现实。第三个红利是语言特性跟得上时代。现在Unity较新版本已经支持到C# 9的特性模式匹配、记录类型、init-only属性、顶级语句这些都能用。你可以写if (state is MovingState { Speed: 0 } moving)这种代码逻辑表达力比传统C写法高不少。属性访问器、LINQ注意别在热路径用、async/await配合UniTask这类库使用都能直接落地。注意C#的便利不是免费的。GC垃圾回收是你在Unity里必须建立直觉的东西后面第6节我会专门讲怎么排查GC引起的卡顿。2.2 IL2CPP这个名字容易让人误会成用C开发游戏这是误解最多的地方。IL2CPP的全称是Intermediate Language To C它的工作流程是把你的C#编译出的IL中间代码转换成C代码再用平台的原生编译器比如Clang、MSVC编译成机器码。注意关键点——你写的是C#不是C。IL2CPP生成的C代码是给编译器看的中间产物你不应该去改它也不需要理解它。它的意义在于三点一是iOS等平台不允许运行时JIT必须AOT编译IL2CPP正好满足二是生成的是原生机器码执行效率通常比Mono的JIT模式更稳定三是代码被编译成二进制逆向难度比Mono的DLL高。很多人看Unity构建日志里一堆.cpp文件在编译就以为Unity底层是C所以我应该学C这个推理跳步了。你写C的收益只在你真的需要写原生插件的时候才会体现出来。IL2CPP也有代价而且不小。构建时间会明显变长尤其是大项目包体会变大反射调用受限一些依赖运行时代码生成的库比如某些老版本的JSON库、依赖Reflection.Emit的方案会直接挂掉泛型实例化需要提前生成遇到没预生成的泛型组合可能在运行时抛异常。这些都是实际项目里会踩到的坑。2.3 一张表看清各语言在Unity项目里的分工下面这张表是我自己整理的项目决策参考你可以直接对照自己当下的需求看。语言在Unity项目中的位置典型用途上手难度我的建议C#脚本层官方完整支持游戏逻辑、UI、状态机、存档、网络层中主力语言必须熟练C原生插件层高性能算法、对接第三方SDK、复用已有原生库高撞到性能墙或必须对接时再上C原生插件层极少数嵌入式库移植、老代码复用高除非手里有现成的C库否则没有理由主动选Lua脚本层第三方方案热更新逻辑、策划可改的数值脚本低需要热更新时评估不是必需品HLSL/ShaderLab渲染层材质效果、后处理、GPU计算中高做画面优化绕不开SQL数据层本地数据查询、排行榜缓存低数据量大时考虑小项目用不上JSON/CSV/YAML数据层配置表、本地化文本极低必用和语言选择无关看这张表你会发现一件事C#覆盖了你能想到的90%以上的日常开发工作。C和C的位置在插件层也就是你主动伸手去够底层的那一层只有两种情况值得伸手——性能真的不够或者必须对接别人给你的原生库。3. 动手验证一个同时用C#、C、Lua的Demo光讲道理没有说服力。我拿一个实际做过的小工具做例子给一个策略类原型做大规模单位位置更新数据统计模块需求是每帧处理10万个单位的坐标积分并统计总血量。这个场景能很好地把三种语言的分工演出来。3.1 C#侧把性能敏感逻辑先写对再写快最开始的版本我直接用C#写的很简单public class UnitSystem : MonoBehaviour { private struct Unit { public Vector3 Position; public Vector3 Velocity; public int Hp; } private Unit[] _units; private void Update() { float dt Time.deltaTime; long totalHp 0; for (int i 0; i _units.Length; i) { _units[i].Position _units[i].Velocity * dt; totalHp _units[i].Hp; } Debug.Log(totalHp); } }这段代码有两个明显问题。第一Debug.Log每帧调用会触发字符串分配和日志系统开销测试阶段必须先干掉。第二单位用struct数组存储是对的访问是连续内存缓存友好比用类数组引用数组快不少这是我一开始就做对的地方。先跑一遍基线10万单位帧耗时大概在0.8毫秒到1.2毫秒之间不同机器差异较大我这里用的是桌面级CPU。这个数字算能接受但还没到稳的程度因为主线程还要跑渲染、UI、物理留给逻辑的预算本来就不多。于是第二步我上Job System Burst把逻辑挪到Worker线程Burst负责把IL编译成高度优化的SIMD代码using Unity.Burst; using Unity.Collections; using Unity.Jobs; using Unity.Mathematics; [BurstCompile] public struct UnitUpdateJob : IJobParallelFor { public float DeltaTime; [ReadOnly] public NativeArrayfloat3 Velocity; public NativeArrayfloat3 Position; public void Execute(int index) { Position[index] Velocity[index] * DeltaTime; } }配合一个小的归约Job统计血量实测下来这个版本稳定在0.15毫秒上下而且在Burst Inspector里能看到生成的汇编里有SIMD指令向量化生效了。这一步没有写一行C纯C#。实操心得Burst对代码有限制不能用托管引用、不能try/catch、不能用大部分.NET类库写起来会有点束手束脚。所以我一般先用普通C#写通逻辑确认算法正确再改写成Burst版本不要在还没跑通的时候就去啃Burst的报错。3.2 C原生插件从编译到落地的完整流程什么时候才轮到C我给自己设的触发条件是Burst版本优化到位后仍占主线程预算的10%以上且这段逻辑无法拆成Job或者需要调用Burst不支持的第三方库。上面这个例子其实没触发但我为了做对比还是写了一个C版本。原生侧代码// NativeMath.cpp #include cstdint #if defined(_WIN32) #define EXPORT_API __declspec(dllexport) #else #define EXPORT_API __attribute__((visibility(default))) #endif extern C { // 返回0表示成功-1表示参数非法 EXPORT_API int SumInts(const int* data, int32_t count, int64_t* outSum) { if (data nullptr || count 0 || outSum nullptr) { return -1; } int64_t sum 0; for (int32_t i 0; i count; i) { sum data[i]; } *outSum sum; return 0; } }这里有几个细节必须强调。用extern C是为了阻止C名称修饰不然C#侧DllImport找不到符号。返回码用int而不是bool因为C的bool跨ABI传回C#时在不同平台上的宽度不完全一致用int最省事。累加用int64避免溢出游戏里血量总和很容易突破21亿这个量级。编译命令按平台分开# Windows在 Developer Command Prompt 里执行 cl /LD /O2 /EHsc NativeMath.cpp /Fe:NativeMath.dll # Android arm64 aarch64-linux-android21-clang -shared -O2 -fPIC NativeMath.cpp -o libNativeMath.so # macOS / iOSiOS 要静态库 clang -c -O2 -fPIC NativeMath.cpp -o NativeMath.o libtool -static -o libNativeMath.a NativeMath.oC#侧封装using System; using System.Runtime.InteropServices; public static class NativeMath { private const string DllName NativeMath; [DllImport(DllName, CallingConvention CallingConvention.Cdecl)] private static extern int SumInts(IntPtr data, int count, out long sum); public static long Sum(int[] values) { if (values null || values.Length 0) return 0; IntPtr buffer Marshal.AllocHGlobal(sizeof(int) * values.Length); try { Marshal.Copy(values, 0, buffer, values.Length); int code SumInts(buffer, values.Length, out long result); if (code ! 0) { throw new InvalidOperationException($native call failed, code{code}); } return result; } finally { Marshal.FreeHGlobal(buffer); } } }文件放置有硬性要求放错了运行时就找不到库Windows的dll放Assets/Plugins/x86_64/Android的so放Assets/Plugins/Android/libs/arm64-v8a/如果要兼容32位再建armeabi-v7aiOS的静态库放Assets/Plugins/iOS/Unity打包时会自动链接进去。实测这个C版本纯求和部分比C#普通循环快大约2到3倍但加上Marshal.AllocHGlobal和Marshal.Copy的开销后整体耗时反而不占优势。这个结果非常重要原生调用不是免费的每次跨托管/原生边界都有固定开销数据拷贝更是实打实的成本。3.3 参数计算到底值不值得跨边界我把这个账算给你看。假设你要处理N个int单次跨界调用开销约在1到3微秒量级不同平台差异大移动端更贵Marshal.Copy的成本约为每字节0.02到0.05纳秒。那么总成本大致是总耗时 ≈ 跨界固定开销 N × 单元素拷贝成本 N × 原生计算成本当N只有几千时第一项占绝对主导你会发现C版本比C#还慢。当N上到百万级拷贝和计算成本开始主导C的优势才显现出来。更优的做法是别拷贝数据——用NativeArray配合NativeArrayUnsafeUtility.GetUnsafePtr直接把指针传给原生侧或者干脆让原生侧自己管理这块内存只把句柄传回C#。这样能省掉整个拷贝环节。所以我的判断规则是单次调用处理的数据量低于1万个元素、或者调用频率高于每秒1000次就别往C送先在C#里用Burst想办法。反过来像音频解码、视频帧处理、复杂寻路、物理碰撞这类单次数据量大、算法复杂度高的活儿C才有明显的性价比。注意原生侧分配的内存一定要由原生侧释放。我见过项目里C#用Marshal.AllocHGlobal分配、C用free释放在Windows上侥幸没崩到Android上直接闪退。内存的分配者和释放者必须是同一个运行时。4. 性能数据与选型判断什么时候真的需要换语言上面那个Demo只是个小切片真正做项目时你面对的是更复杂的决策环境。这一节我把实测数据、判断逻辑和新手最关心的学习路线都摊开讲。4.1 一次环形数组求和的实测对比我做过一组对比测试场景是对一个30万条记录的环形缓冲做遍历聚合分别用四种实现方式在同一台机器上跑1000次取平均实现方式平均耗时相对性能备注C# 普通循环数组0.62 ms1.0x基线含GC压力C# Span unsafe指针0.41 ms1.5x需要开启Allow unsafe CodeC# Burst Job0.11 ms5.6x多线程SIMDC 原生插件含拷贝0.38 ms1.6x拷贝开销吃掉大半优势C 原生插件零拷贝传指针0.13 ms4.8x需要内存由原生侧管理这组数据的结论很有意思纯C插件在零拷贝前提下才勉强和Burst打平算上拷贝就完全被吊打。原因在于Burst会把循环自动向量化一条SIMD指令处理4到8个元素而手写的C循环如果不加#pragma omp simd或者不用intrinsics编译器不一定帮你做这件事。这也解释了为什么这些年Unity社区越来越少提上C优化转而都在讲DOTS、Burst、Jobs。工具链的进步改变了性价比的天平。实操心得想开unsafe代码在Player Settings里勾上Allow unsafe Code然后在代码里用unsafe关键字包住指针操作。别怕数组越界这种事在Span体系下比裸指针安全很多SpanT和MemoryT是更推荐的第一选择。4.2 选型决策树照着走不会错我把这些年的判断经验整理成一条决策链遇到性能问题按顺序走先确认瓶颈位置。用Profiler抓一份数据看是CPU主线程、渲染线程、GC还是物理。90%的性能问题其实定位错了地方。检查是不是写法问题。每帧GetComponent、每帧字符串拼接、每帧LINQ、频繁装箱把int传给object参数、大量Instantiate/Destroy这些是常见元凶改完往往能省一半开销。上对象池和缓存。把频繁创建的GameObject、List、数组都池化把组件引用在Awake里缓存好。这一步的收益通常比换语言大得多。考虑Job System Burst。适合可以并行、数据相互独立的计算。注意数据依赖需要写入同一块内存的任务别并行。考虑原生插件。前面四步都做完还是不够且数据量足够大才考虑这一步。最后考虑架构层面的改动。比如把一部分逻辑挪到服务端、降低模拟频率、用LOD思路减少计算量。这往往比语言层面的优化更有效。4.3 新手最常问先学C语言还是先学C#每次讲这个话题评论区必有人问我零基础是不是应该先学C语言打基础我的回答一直是如果你目标是做Unity3d游戏开发直接学C#不要绕道C语言。绕道C语言的问题在于C语言教你的东西——手动内存管理、指针运算、宏、结构体对齐——在Unity脚本层基本用不上而它不教的东西——面向对象设计、事件驱动、托管内存模型、异步编程——恰恰是你每天要用的。我见过太多人在C语言上耗了三个月回头写Unity脚本还是不知道怎么组织一个状态机。那C语言在什么情况下值得学两种情况。一是你打算做引擎或工具链开发需要理解底层原理二是你的项目必须移植一个有大量C代码的第三方库比如某些音视频处理库。注意第二种情况里出现的关键词是必须移植不是想优化。顺便提一句如果你对C语言的指针和内存模型确实好奇我建议的路径是先用C#做两个完整的小项目建立对游戏循环和对象生命周期的直觉再回去看C语言的指针章节。这时候你会发现理解速度快很多因为你知道这些概念在解决什么问题了。至于那些C语言必背100代码字符串逆序C语言之类的练习题作为编程思维的训练是有价值的但和Unity3d游戏开发的关系并不直接。时间有限的话把精力投在C#、Unity API、以及一个完整的项目实践上回报率高得多。5. 跨引擎视角的旁证Godot与UE5的语言选择有时候看别的引擎怎么选语言能反过来印证Unity的选择是不是合理。这个横向视角对做技术选型的人特别有用。5.1 Godot的GDScript、C#与GDExtensionGodot走的是另一条路它自己造了一门语言GDScript语法接近Python专门为游戏逻辑设计和引擎的节点系统深度绑定。同时它支持C#.NET版本也支持通过GDExtension用C写扩展。GDScript的优势是轻、快、上手门槛极低改代码不用等编译。劣势也很明显性能不如C#生态和第三方库远不如.NET丰富大型项目里代码组织和重构会比较吃力。这个对比说明了一件事引擎自研脚本语言和采用通用语言是两条不同的取舍路线。自研语言能做得更贴合引擎但生态要靠自己养采用通用语言能白嫖整个生态但要忍受语言和引擎之间的适配缝隙。Unity选择了后者代价是早期要维护多套绑定好处是今天你有海量的C#资料、库、工具可以直接用。5.2 UE5的C与蓝图为什么不选C#UE5的主语言是C配合蓝图做可视化脚本。很多人问为什么UE不学Unity用C#。核心原因是UE的架构设计从一开始就是围绕C的反射系统和垃圾回收机制展开的它的UObject体系、属性系统、序列化机制全都依赖C的宏和模板。要换成C#等于把整个底层重写一遍。反过来说Unity选择了C#也是因为它从一开始就把脚本层设计成和引擎内核解耦用绑定层连接。两种架构各有代价UE的C开发效率低一些但底层控制力强Unity的C#开发效率高但深入底层的路径更窄必须走插件。我自己的判断是引擎选什么语言本质上是这套引擎的设计目标决定的不是语言本身的优劣之争。你做Unity3d游戏开发就顺着C#这条主路走需要底层能力时用插件补这个模式已经被验证过无数次了。6. 常见问题与排查实录理论和数据讲完了下面是真刀真枪的部分。这些都是我在项目里踩过的坑整理成速查表方便你对照。6.1 编译、链接、运行时错误速查报错信息真实原因解决方式DllNotFoundException插件没放进正确的平台目录或架构不匹配检查Assets/Plugins/下的子目录名Android要区分abiEntryPointNotFoundExceptionC侧没加extern C符号被名称修饰加extern C或用dumpbin /exports查看导出符号MarshalDirectiveException参数类型不匹配比如C的bool对C#的bool统一用int传递布尔值IL2CPP构建后反射失效代码裁剪把用到的类型裁掉了添加link.xml保留程序集或关闭高等级裁剪TypeLoadException泛型相关IL2CPP没有预生成这个泛型实例在AOT场景下显式使用一次该泛型组合Burst编译报错用了托管类型或try/catch改用NativeArray去掉异常处理排查DllNotFoundException有个小技巧打开Player Settings里的Development Build和Script Debugging日志里会打印它尝试加载的完整路径对照路径就能看出是目录放错还是文件名大小写问题。Android上尤其要注意so文件名必须带lib前缀但C#里DllImport写的是不带前缀的名字。6.2 性能与GC问题排查GC引起的卡顿有几个典型特征帧率曲线每隔几秒出现一次尖峰、Profiler里GC Alloc一栏持续飙红、卡顿间隔和某个操作频率一致。定位方法是在Profiler里开Deep Profile看是哪个函数在持续分配。常见的GC来源按出现频率排序字符串拼接。HP: hp这种写法每次都会分配新字符串。改成StringBuilder或者用TMP的SetText重载直接传数值。装箱。把值类型传给object参数比如Debug.Log(123)、string.Format({0}, 123)都会装箱。用泛型重载或者SetText的数值版本规避。闭包捕获。lambda里捕获了循环变量或者外部对象会生成新的闭包类实例。热点路径上避免用lambda。LINQ。Where、Select每次都会分配迭代器。Update里绝对不要写LINQ。数组与List的频繁创建。new Listint()每次都会分配。用对象池或者复用已有实例。注意List内部数组扩容也会分配初始化时给个合理的容量。协程的new WaitForSeconds。每次yield都new一个改成缓存静态实例。实操心得判断一段代码有没有GC分配最简单的办法是打开Profiler勾上GC Alloc列看这个函数在单帧里分配了多少字节。目标是热路径上0字节。我习惯在项目早期就把这个指标卡住等到后期再来清理成本会高得多。6.3 原生插件与跨平台踩坑清单写C插件这些年我总结的坑大致是这几类内存归属问题。前面提过分配和释放必须同一个运行时。跨边界传递的内存建议约定清楚谁负责释放最好写成注释贴在函数头上。字符串编码问题。C#的string是UTF-16C的char*通常是UTF-8。传字符串进原生侧要么约定编码要么用Marshal.StringToHGlobalAnsi转换记得释放。这个坑主要出现在对接第三方SDK时。结构体布局问题。C#传给C的struct必须加[StructLayout(LayoutKind.Sequential)]字段顺序要和C侧完全一致而且要注意对齐。C默认按4或8字节对齐C#默认按Pack8两边不一致时同一块内存解读出来的值会错位。必要时在C#侧用Pack 4显式指定。iOS的静态库链接。iOS不允许动态库必须提供.a静态库。Unity会自动链接Assets/Plugins/iOS/下的文件但如果有多个架构真机arm64 模拟器x86_64需要用lipo合并成fat二进制。Android的STL问题。C插件如果用了STL要确保和Unity使用的C运行时一致。以前踩过用_sharedSTL编译导致符号冲突的坑后来统一改成-static-libstdc就稳了。6.4 小游戏与小程序场景的语言限制现在很多团队会把Unity项目导出成小游戏版本这条路上的语言限制比原生平台严得多。核心约束是运行时不能JIT编译代码这意味着不能使用System.Reflection.Emit动态生成代码不能在运行时编译C#字符串依赖动态代理的库某些AOP框架、老版JSON库会失效Expression.Compile()这类API不可用。另一个约束是包体大小。小游戏平台对首包体积有硬性上限这就要求你把代码裁剪开到比较高等级把没用到的程序集全裁掉。裁剪等级开高之后反射失效的风险会同步上升link.xml就变成必需品了。还有多线程限制。部分小游戏环境对线程的支持是受限的Job System在这种环境下能不能跑起来、能不能拿到实际并行收益需要你在目标平台上实测不能直接照搬移动端的结论。注意如果你打算做跨平台发布PC 移动小游戏最省事的做法是把平台相关的代码全部用条件编译包起来比如#if UNITY_WEBGL !UNITY_EDITOR让不适用的分支在构建时直接消失。千万不要在运行时用if判断平台那样被裁掉的代码依然会占体积。7. 我个人在实际项目里的语言使用习惯做了几年下来我的实际习惯已经非常固定了打开Unity新建脚本默认就是C#一年到头可能只有两三次真正需要写C。那两三次通常发生在对接硬件SDK、做音频重采样、或者需要移植一个有大量现成C代码的算法库时。C语言我基本只在读别人的代码和看编译错误时打交道。如果你的项目现在是起步阶段我建议你把精力分成三份七成放在C#和Unity API的熟练度上两成放在性能意识Profiler怎么用、GC怎么避、数据结构怎么选上剩下一成了解一下原生插件的接口约定就够了。等你真正遇到需要C的问题时你会发现难点从来不是会不会写C而是能不能准确定位到瓶颈在哪。最后分享一个我常年用的自检习惯每次提交代码前扫一眼Profiler的GC Alloc热路径上如果出现非零分配就当bug处理。这个习惯帮我省下的性能优化时间比任何语言选择带来的收益都大。