嘿，这两个问题问得很到位，刚好是很多开发者在性能优化时会纠结的点，我结合多年的实践和编译技术发展来给你唠唠：

2018年的时候，主流编译器（比如GCC、Clang、VS的MSVC）已经具备不错的自动内联能力，但手动内联或者合理标记内联的场景，性能优势还是要看具体情况：

• 对于几行代码的极小函数（比如简单的数值计算、getter/setter），内联能完全消除函数调用的开销——包括栈帧创建、参数传递、返回地址跳转这些步骤。如果这类函数在循环里被高频调用，性能提升可能能达到10%-30%，极端场景下甚至更高。
• 对于中等或大型函数，强行内联反而会适得其反：代码膨胀会导致指令缓存（ICache）命中率下降，CPU需要频繁从内存加载指令，这个开销远大于函数调用的成本，最终整体性能会变慢。
• 另外2018年的时候，跨单元的内联优化（比如链接时优化LTO）已经开始普及，但还不是所有项目都会默认开启，所以如果函数在不同编译单元，手动内联或者标记inline（C++里）能帮助编译器做优化。

放到现在（2024年及以后），这个问题的答案已经很明确：不要优先选择内联，模块化、可读性优先，剩下的交给现代编译器。原因和通用准则如下：

现代编译器的优化能力已经远超手动判断 #

现在的编译器能做自动内联、函数拆分、循环展开、跨单元优化、甚至基于机器学习的优化决策，它会根据函数的大小、调用频率、缓存友好度等多个维度自动决定是否内联，比开发者手动判断精准得多。

关于你举的例子：const a = (x) => { b(c(d(x))) } #

内联后绝对不是必然更快：

• 如果b、c、d都是无副作用的纯函数，且逻辑简单，编译器会自动把整个调用链展开成直接计算，不管你是写成嵌套函数调用还是手动内联成一行，最终生成的机器码（或者JS引擎的字节码）几乎没有差异，性能完全一样。
• 如果这些函数有副作用、依赖外部状态，或者逻辑复杂，手动内联可能会让代码结构变乱，编译器反而无法做其他优化（比如公共子表达式消除），甚至因为代码膨胀导致缓存命中率下降，反而变慢。

通用经验法则 #

• 先写清晰、模块化的代码：把逻辑拆成职责单一的小函数，优先保证可读性和可维护性——这对长期项目来说比那一点点可能的性能提升重要得多。
• 用性能分析工具说话：只有当你通过profiling（比如Chrome DevTools、perf、VTune）明确发现某个函数调用是性能瓶颈时，再考虑手动内联或者调整编译器优化选项。
• 循环内的高频小函数可以尝试手动内联，但一定要对比profiling结果——很多时候编译器已经帮你做了同样的优化。

内容的提问来源于stack exchange，提问作者Undistraction