在我开始学习如何使用jQuery 库之前，我想向自己保证一些与文件大小有关的事情......
我很清楚浏览器和服务器会缓存诸如 jQuery 之类的文件——理论上，这意味着该文件应该只下载一次，因此提高了后续使用的速度。
我的问题更多的是关于浏览器如何处理 javascript 文件，以及每次加载页面时浏览器处理 32k 代码文件是否会产生不利影响？这不仅是文件的大小，还包括文件的复杂性。
还是我的理解不正确，浏览器不仅缓存了javascript文件，而且还缓存了该文件的某种“编译”版本？（是的，我知道javascript 实际上并没有“编译”，但希望你知道我的意思。）
我想大多数浏览器都能够足够快地处理文件，以至于几乎没有什么区别，而使用 jQuery 来处理更少的代码所带来的速度优势弥补了这一点。
您对资产大小和 js 引擎性能的担忧有一些您需要考虑的重叠因素。最终，只有您能够确定什么适合您的项目/可以接受。
可能说明显而易见，但我们将从这里开始。
您必须减少页面消耗的资产大小的任何机会都是一件好事。保持你的标记、样式和 js 精简。避免采用这样的心态，即您的用户群将始终拥有可供他们使用的高速连接。例如，考虑移动受众以及他们的连接速度将如何波动。快速加载的页面是获得出色用户体验的第一步。
修剪脂肪并确保您已验证将 jQuery 包含到您的项目中。
您的陈述“在我开始学习如何使用 jQuery 库之前”让我相信您可能是 Web 开发和 js 开发的新手。不是为了挖掘你或你的问题的有效性，但这个假设将推动我去这里的地方。
总体而言，将自己暴露于 jQuery 库将是一件好事，即使它不是您项目的正确选择。
多年来，jQuery 库已经成熟为非常出色的东西，并为每天的跨浏览器 js 问题提供了一些优雅的解决方案。浏览源代码并了解一些实现的概念只会对您有所帮助。
此外，jQuery 无处不在。无论您可能形成任何个人意见，jQuery 都是开发人员工具箱中最流行的库之一，而且似乎不会出现在任何地方。即使您从未在从头开始开发的项目中使用 jQuery，您也一定会在此过程中遇到某个地方。熟悉库只会使您的开发工作受益。
最终，您需要评估为什么要考虑将 jQuery 引入您的项目。它只是您最常使用的选择器引擎吗？如果您正在执行基本的 DOM 操作并且只需要一个好的选择器引擎，请考虑直接使用Sizzle，它只有 4KB（压缩和 gzip 压缩）。
也许 jQuery 是您想要包含的一个很酷的插件的依赖项。您可以自己重写它以将其精简吗？调整工作大小并检查努力是否值得节省可能的文件大小。如果您只节省几 KB，但需要 40 小时来完成工作，是否值得？
创建浏览器支持矩阵。您支持的浏览器不仅会直接影响速度，还会直接影响资产的大小。
检查支持的 js 引擎的性能差异。这将允许您预测页面上 js 的速度，从那里您可以对您认为可以接受的内容做出任何让步。
请记住 js 的质量和完整性（包括你的和 jQuery 等库的）也会极大地影响性能。更快的 js 引擎（例如Chrome 的V8）可能会更宽容编写糟糕的 js，因为IE7 的JScript可能会暴露缺陷并大大降低性能。
jQuery 是一个库，它肯定会在为核心编写的 js 中考虑性能。您可能会发现大多数性能受到挑战的 jQuery 都来自可能无法进行广泛的跨浏览器基准测试的 3rd 方插件。
如上所述，jQuery 打包了许多跨浏览器修复，以解决 DOM API 支持中的各种差距。这可能会为您节省大量精力或增加一些可能不需要的膨胀。检查您的支持矩阵倾向于哪种方式（旧浏览器与现代浏览器）并确定这可能如何影响您的项目。如果您发现自己只针对最新最好的浏览器，可以想象您可以编写自己的 jQuery 建模库，仅添加项目所需的功能。不要忘记调整工作的大小，看看它如何影响底线。
底线是，如果您的项目严重依赖 js 来辅助功能和用户体验，那么很难说使用 jQuery 将是一个糟糕的选择。当您考虑所需的工作量时，您可能没有可用的工时来编写更精简/更高效的代码。想想不仅要编写一个等效的库（即使删减了特性），还要考虑维护它所需的努力。您需要与一大群开发人员保持一致的编码能力才能跟上步伐。
不管你决定什么，祝你好运！