企业官网建设流程全解析

相信很多刚入行的朋友都有过这种经历：跟着教程配置环境，一会儿提示“Android SDK missing”，一会儿报“library not found”，打开官方文档又看到一堆“API”“SDK”“Library”的术语来回出现，整个人直接懵掉。

我当年第一次接触“深视智能相机SDK”的时候，也是这样——下载下来一个压缩包，里面又是头文件、又是动态库、又是示例工程，根本分不清哪部分是“SDK”，哪部分是“API”，更别说什么Library了。后来在嵌入式、客户端、服务端都折腾过一圈，才慢慢理清这三者的关系。

这篇文章就用最直白的话，把SDK、API、Library这三个概念讲透。不需要你有很深的技术底子，只要写过几行代码，哪怕只写过简单的脚本，也能看懂。看完之后你至少能回答三个问题：它们各自是什么？有什么区别？实际开发中遇到问题，怎么判断是哪个环节出的错？

1. 先搞懂三者的定位：一个生活化的类比

想理解三者的区别，最有效的方式是先建立一个直觉模型。技术上抠定义很容易绕晕，但用生活场景去类比，一下就通了。

1.1 把Library理解成“工具箱”或“预制菜”

Library（库）是一堆已经写好的、可以被复用的代码。你把它拿过来，当成自己的代码一样调用里面的函数。

打个比方，库就像是超市里的预制菜——鱼香肉丝已经切好、配好料、调好酱汁，你买回家只需要下锅炒一下。你不需要自己去买菜、洗菜、切菜、调酱汁，但你仍然要自己掌控火候、自己决定什么时候出锅。

代码里的情况一模一样：你要处理JSON数据，不需要自己写一遍JSON解析器的全部逻辑，直接引入一个开源的JSON库，调用它的解析函数就行。控制权在你手上，库只是提供“半成品”，怎么用、什么时候用、用得对不对，都是你代码里说了算。

1.2 把API理解成“餐厅的点餐窗口”

API（Application Programming Interface，应用程序编程接口）是一套“接口约定”。它不给你任何代码实现，只告诉你：“你按这个格式请求，我就按那个格式返回。”

这就像餐厅的点餐窗口。你不需要知道后厨是怎么炒菜的、用了什么锅什么灶，你只需要按菜单点菜，服务员把菜端给你就行。你点的菜名是“请求参数”，端上来的菜是“返回结果”。至于后厨的情况，你一概不用管，也管不着。

API的核心特征是：它定义的是“双方通信的规则”，而不是“替你干活的工具”。最常见的REST API，就是你向某个URL发一个HTTP请求，服务器返回一段JSON，你就是通过API在跟另一个系统打交道。

1.3 把SDK理解成“装修公司的全包服务”

SDK（Software Development Kit，软件开发工具包）是一个“大礼包”。它不仅包含Library，往往还包含API封装、文档、示例代码、调试工具，甚至包括配套的IDE插件。它存在的意义是：让你针对某个特定平台、硬件或服务快速开发，省去从零起步的麻烦。

类比一下，SDK就像你找了一家装修公司做全包。设计师给你出方案（文档），工人带着全套工具上门施工（工具链），材料由公司统一配好（库和依赖），项目经理帮你盯着进度（调试工具）。你只需要提需求、验收结果。当然，代价是你基本得按这家公司的流程和标准来——你说“我想不用你们的水泥”，那就没法合作了。

1.4 一句话总结区别

• Library是“给你材料，你自己做”。
• API是“你点单，别人做好端给你”。
• SDK是“整包服务，你只管提需求”。

这三者不是并列关系，SDK里面往往会同时包含Library和API，还额外带了一整套开发配套资源。这也是为什么很多大厂的SDK动辄几百兆——它要把你开发时可能需要的所有东西都准备齐。

2. Library（库）：代码世界的“半成品仓库”

理解了大概轮廓，我们逐一把每个概念抠细一点。先看Library，因为它是三者中最好理解、也是你每天都在用的东西。

2.1 什么是Library

Library是一组可复用的代码集合，里面封装了某个或某些功能。它通常以特定形式交付，常见的有这么几种。

• 静态库：编译时直接链接进你的可执行文件里。Windows下常见是.lib（配合静态编译），Linux下是.a文件。特点是发布程序时不需要额外携带库文件，但程序体积会变大。
• 动态库：运行时才加载，你的程序里只保留一个引用。Windows下是.dll，Linux下是.so，macOS下是.dylib。特点是多个程序可以共享同一个库，但发布时必须保证目标机器上存在对应版本的库，否则就会报“XXX library not found”。
• 源码库：直接以源码方式引用，像很多开源项目一样，你把源码拉下来编译进自己的程序。

2.2 你早就用过Library了

很多人觉得自己“没用过库”，其实早就用过了。比如前端用的React、jQuery，Python里的requests、pandas，C++里最常见的OpenSSL，Java里的Apache Commons，这些全都是Library。

它们共同的特征是：你写代码时主动调用它们提供的函数或类，程序的流程控制权始终在你手里。

比如下面这段Python代码，就是典型的“使用库”：

import requests response = requests.get("https://example.com/api/data") data = response.json() print(data)

这里requests就是一个Library。你把它的get方法拿过来用，但调不调用、什么时候调用、拿到结果怎么处理，完全是你在掌控。Library不会反过来通知你、不会主动执行什么东西。

2.3 为什么会有“library not found”这类报错

搜索引擎里很多人搜“missing required library”“device library error detected”“cannot mix incompatible qt library”，这些报错的根源，基本都是Library的使用出了问题。常见原因有三类：

• 路径不对：程序在编译或运行时找不到对应的库文件。原因是库的路径没有加到环境变量（如Linux的LD_LIBRARY_PATH、Windows的PATH）里，或者IDE里没有配置好库搜索路径。
• 版本不匹配：编译时用的库版本和运行时加载的版本不一致。热词里那条“cannot mix incompatible qt library (5.15.3) with this library (5.15.2)”就是典型例子——你程序编译时对着Qt 5.15.2的头文件编译，运行时却加载到5.15.3的动态库，两边的二进制接口对不上，直接崩溃。
• 架构不匹配：库文件是32位的，你的程序是64位的，或者库是为ARM编译的，你的环境是x86，同样会加载失败。

我见过最耗时的一个“library not found”，是同事把一个第三方库的头文件路径配置到了另一个目录，结果报错一直指向“找不到头文件”。他查了一下午，最后发现是CMakeLists.txt里INCLUDE_DIRECTORIES写错了路径。这类问题没什么捷径，只能一步一步排查路径、版本、架构三个维度。

2.4 小结：Library的本质

Library的本质是“代码复用”。它帮你省去重复造轮子的时间，但你的程序依然是主角，库只是配角。判断某个东西是不是Library，只需要问一句：是我在调它，还是它在调我？是我在控制流程，还是它在控制流程？如果是前者，那它基本就是个Library。

3. API（接口）：服务之间说话的“标准协议”

如果说Library是你自己家厨房里的预制菜，那API就是外送点餐的电话。你打个电话过去，报上菜名，然后等着对方的反馈。至于对方怎么做菜、用谁家的肉、厨师的刀工怎么样，你统统不知道，也不需要知道。

3.1 什么是API

API是一组“约定好的调用规则”。它定义了两部分内容：

• 请求方应该怎么调用（方法名、参数、格式、认证方式等）
• 服务方返回什么（数据结构、错误码、状态信息等）

API本身不包含实现代码，它只是“合同”。谁来实现这个API、怎么实现，那是服务方的事。这带来一个非常大的好处：调用方和服务方可以完全解耦。

最常见的例子就是Web API。你在代码里发起一个HTTPS请求：

curl -X GET "https://api.weather.com/v1/city/101010100" -H "Authorization: Bearer your_token"

返回来的是一段JSON结构。你在调用之前可能需要看一眼API文档，确认/v1/city/后面要接什么参数、返回字段叫什么名字。这就是“按合同办事”。

3.2 API的几种形态

很多人以为API就是HTTP接口，其实不全是。API这个概念非常广，至少有这几种常见形态。

• REST/HTTP API：基于HTTP协议，用URL加方法（GET/POST等）来调用，返回JSON/XML。这是目前最主流的后端服务交互方式。
• 库函数API：任何一个Library都会暴露一组函数或类，这些函数签名本身就是API。比如你调用strlen()，这就是C语言标准库提供给你的API。
• 系统调用API：操作系统提供给应用程序的接口，比如Windows的Win32 API、Linux的POSIX API。
• 硬件API：硬件厂商封装好的控制接口，比如摄像头、传感器的SDK底层的调用接口。
• 编程语言标准库API：比如Java标准库里的String、List，这些类的方法就是API。

说这些是想让你明白：API是一种更底层的概念，它是一种“约定”；HTTP API只是API的一种实现方式，Library里的每个公开函数其实也都是API。

3.3 为什么API会限制调用次数

工作中很多人都会遇到“api调用量超限”“api error: 429 exceeded quota”这类报错。这不是你的代码写错了，而是API服务方为了保护自己的服务器，给你设定了调用配额。

因为API是“给别人提供能力”的服务，提供方要承担服务器成本。如果某个调用方一口气发几万个请求，后端可能直接被拖垮，影响其他用户。所以几乎所有公开API都会做限流：

• QPS限制（每秒请求数）
• 日调用量限制
• 并发连接数限制

处理这种问题，标准做法是加本地缓存、控制频率、做好指数退避重试。千万不要一看到429就疯狂重试，那只会让你的IP被封得更久。

3.4 API和Library的真正区别在哪

这是很多人最迷糊的地方。网上一堆文章说“API是接口，Library是库”，但这句话其实没法真正帮你区分。

核心区别就一句话：Library是代码实体，是拿给你用的工具集；API是通信协议，是双方沟通的合同。你引入一个Library，它的实现代码就在你的进程里跑；你调用一个API，真正的实现可能在千里之外的服务器上，你的进程里只有“打电话”的客户端代码。

另一个重要区别是控制权。用Library时，函数调用的返回值、错误处理、流程控制全在你这边。但用API调用远程服务时，你只能按对方定义的格式发送请求，对方返回什么结构你就得解析什么结构——你没有机会看到对方内部的任何实现细节。

最直观的体验就是：如果一个远程API挂了，你的代码再正确也会报错；而一个本地Library只要编译进去，它就不会因为你网络不好而失败。

4. SDK（开发工具包）：把“工具+说明书+示例”打包发货

前面我们说SDK是个“大礼包”，现在展开讲讲这个大礼包里面到底有什么。

4.1 SDK的组成

SDK（Software Development Kit）是软件开发者工具包的缩写。它的目标是：降低你使用某个平台、硬件、服务进行开发的门槛。不同厂商的SDK内容不完全一样，但基本都会包含下面这几类东西：

• 库文件（Library）：通常是预先编译好的.so、.dll、.lib、.jar、.aar等。
• API封装（API binding）：对底层能力做一层封装，让你不用直接跟复杂的原生接口打交道。比如相机SDK会封装好“打开相机”“抓图”“调曝光”等方法。
• 头文件或接口定义：告诉你有哪些类和函数可以调用，参数是什么。
• 文档（Documentation）：API参考、开发指南、常见问题。
• 示例代码（Sample/Demo）：官方写好的示例工程，可以直接跑起来验证环境是否OK。
• 调试工具或配套工具链：比如Android SDK里的adb、emulator、platform-tools。
• 配置文件或依赖清单：比如Android SDK里不同版本的platform和build-tools。

换句话说，SDK=（多个）Library+（封装的）API调用+文档+示例+工具，是一个“全家桶”。

4.2 用几个实例理解SDK

• Android SDK：这是最典型的SDK。它包含了Android平台的各种库（如android.app.Activity、android.view.View）、构建工具（如aapt2、d8）、调试工具（如adb、Android Studio插件）、模拟器镜像、不同API Level的Platform包等。你现在写Android App，本质上就是在调用Android SDK需要的API，而这个SDK帮你把整个Android系统的能力都暴露出来了。
• 相机厂商SDK：比如深视智能相机SDK，里面通常包含相机SDK动态库、开发头文件、C++/C#/Python示例工程。你不需要直接去研究USB或GigE接口协议，SDK把底层图像采集逻辑封装好了，你只需要打开相机，然后拿图。
• Vivado SDK / Xilinx SDK：这是FPGA开发中的SDK，针对特定芯片平台。它不仅提供库函数，还集成了一套交叉编译工具链，让你可以在开发电脑上编写、编译用于FPGA内嵌ARM处理器的程序。
• Vercel AI SDK：这是一套面向AI应用开发的SDK，里面封装了与大模型交互的API客户端、UI组件、流式传输等能力。
• 微信语音通话SDK：提供录音、编解码、网络传输、播放等一整套能力，你集成后就能在自己的App里实现语音通话功能，不用从零搞定音频采集和传输。

4.3 SDK和API、Library的关系

现在可以把三者的关系画成一张概念图来理解了。

SDK是一个“层级更高”的包。它内部会依赖API（比如调用平台级API或远程服务的API），也会包含多个Library（比如网络库、编解码库）。SDK对外呈现给开发者的，是一套面向场景的工具集。

举一个具体的例子：你下载了一个“百度地图SDK”，它的内部包含网络请求库（Library），包含调用地图服务的接口（API），还内置了一些UI控件和地图渲染相关能力。你只需要集成这个SDK，不用分别去适配底层网络、渲染引擎和地图数据协议。

所以你可以把关系理解成：

• API是“规则说明书”。
• Library是“实现好的零件”。
• SDK是“一套组装好的解决方案，里面既有零件，又有说明书，还有装配工具”。

4.4 使用SDK时最容易踩的坑

SDK是打包好的东西，看起来很省事，但真正用起来，坑一点都不少。

• 版本号迷思：SDK内部各个组件的版本必须匹配。比如Android SDK，如果platform版本和build-tools版本相差太远，构建的时候就会报一堆奇奇怪怪的错。之前热搜词“android toolchain - develop for android devices (android sdk version 37.0.0)”对应的就是在配置Flutter环境时，需要下载匹配的Android SDK组件。
• 环境变量：很多SDK要求你把根目录加到系统环境变量里。比如Android SDK需要配ANDROID_HOME，否则构建工具根本找不到SDK在哪。
• 动态库路径：不少SDK发布时包含的是动态库，运行你的程序时必须保证能找到这些.dll/.so文件。在Windows上就得放到可执行文件旁边或加入PATH，在Linux上要用LD_LIBRARY_PATH。
• 许可和密钥：很多云服务的SDK需要你填入API Key或Token。热搜词“login failed. check api token or gitlab version”虽然是GitLab工具链的问题，但本质上也是没有正确提供认证信息导致的，SDK调用不通时先查密钥对不对。

5. 三者到底怎么区分：一张对照表 + 记忆方法

道理都讲完了，可能还是有人觉得“有点绕”。没关系，我给你整理一张对照表，再给一个记忆方法，你以后面试也好、写博客也好，直接照着用就行。

5.1 核心维度对照表

三句话做终极区分：

• 如果你问“这个东西能在我的代码里直接调用吗？它跑在我这边吗？”——是的话，它大概率是Library。
• 如果你问“我要发一个什么格式的请求，才能拿到数据？真正的实现在别处吗？”——说明你在用API。
• 如果你下载了一个压缩包，里面有文档、示例、工具、库，并且文档里说“按这套流程集成，就能用某平台/设备的能力”——你拿到的就是SDK。

5.2 一个记忆方法：从点外卖到开餐厅

再换个角度帮你记忆。

• Library就像你自己厨房里的各种半成品食材和酱料包。你决定做什么菜，然后把它们组合起来做。
• API就像外卖平台的统一下单入口。你告诉第三方平台“我要一份咖啡”，平台把订单推给商家，商家做好后由骑手送过来。你只接触到平台和骑手，不接触商家的后厨。
• SDK就像你加盟了一个连锁品牌。品牌方给你提供统一装修方案、配方、物料、培训教程、开店工具，你按总部的标准开一家店，所有环节都标准化了。

5.3 实际项目中到底怎么选

知道区别之后，最关键的是知道“怎么选”。我把多年的经验浓缩成三类场景：

第一类，只要某个基础能力，比如解析JSON、处理图片，直接找一个成熟的Library就够了。没必要引入一个大而全的SDK。

第二类，你的服务需要跟第三方系统交换数据，比如微信支付、天气预报服务。这时候用API最合适，发HTTP请求拿到结果，简单直接，不用下载任何SDK。

第三类，你要针对某个硬件设备或平台做深度集成，比如用相机SDK做一套视觉检测软件、用Android SDK开发原生App。这时候别想太多，老老实实下载官方SDK。它会帮你把低层协议、认证、打包等问题一并解决，比你自己造轮子省太多时间。

如果你只有很短期的需求，比如“临时获取一次地图坐标”，可能一个轻量的HTTP API就能搞定了。但你如果要做成产品级应用，比如App里长期集成地图、定位、导航，那还是引入官方SDK更稳，功能覆盖面和稳定性都会好很多。

6. 真实开发中的报错，能帮你反向理解三者的边界

理论说了这么多，不如来点实战。下面我用几个真实的高频报错场景，带你逐步判断问题到底出在SDK、API还是Library这一层。这个过程本身，就能帮你把三者的边界彻底搞清楚。

6.1 报错场景一：Cannot determine path to 'tools.jar' library for 17

这个报错完整信息一般是：

Cannot determine path to 'tools.jar' library for 17 (D:\soft\jdk17)

先判断一下：这里出现的“library”是SDK还是Library？

其实这个报错里的tools.jar是JDK自带的一个工具库，在JDK 8及之前位于JRE的lib目录下。但从JDK 9开始，模块化改造后，tools.jar被拆分了，路径也就变了。你使用的是JDK 17，某些构建工具还在用老方法去查找tools.jar，自然找不到。

这属于典型的“Library路径/版本兼容”问题。排查思路是：

• 检查你的构建工具版本是否太老，不支持JDK 9+的目录结构。
• 检查JAVA_HOME环境变量是否指向了正确的JDK安装目录。
• 检查项目里是否有写死的老版本JRE路径。

它的关键词是“library”，本质上是工具链和系统库之间的路径匹配失败。

6.2 报错场景二：cannot mix incompatible qt library（5.15.3）with this library（5.15.2）

这个报错信息直译过来是：不能把Qt 5.15.3的库和5.15.2的库混在一起用。

这就是最典型的Library版本冲突问题。你在编译某个第三方库时，它用的Qt版本是5.15.2；而你的主程序链接的是5.15.3。运行的时候，两个库的符号版本不一致，导致二进制兼容问题。

这种问题的排查思路：

• 检查你系统里装了哪几个Qt版本，确保用ldd（Linux）或Dependencies（Windows）查看程序实际加载的Qt库路径。
• 检查第三方库编译时用的Qt版本是否与主程序一致。
• 如果依赖某个CMake工程，在CMakeLists里显式指定Qt的路径，避免多个版本混用。

注意，这跟API没关系，因为不是通信协议的问题，纯粹是Library的二进制兼容问题。这也说明Library层面最常见的坑就是“版本和路径”。

6.3 报错场景三：FileNotFoundError: cannot find DGL C++ GraphBolt library

这个报错看起来很长，其实拆开看特别清晰：

FileNotFoundError: cannot find dgl c++ graphbolt library at /root/shared-nvme/conda-envs/llmgnn/lib/python3.10/site-packages/dgl/graphbolt/libgraphbolt_pytorch_2.8.0.so

这里涉及的是Python的库导入失败。DGL是一个图神经网络库，它的C++扩展Library路径在报错里已经显示出来了，但找不到对应文件。

这种情况通常是：

• Python扩展库安装不完整，比如pip install时有些编译产物没放进去。
• 或者你安装了多个环境，A环境的Python进程却去B环境找库。
• 或者是版本不匹配，DGL的版本和PyTorch的版本不兼容。

排查方向是重新安装DGL、检查Conda环境是否激活正确、确认PyTorch版本是否符合DGL要求。这个报错再次验证了：Library是实体文件，找不到文件是它最常见的失败模式。

6.4 报错场景四：chooseImage:fail api scope is not declared in the privacy agreement

这是个API报错。在微信小程序或某些平台环境里，你调用了一个API（比如选图片的chooseImage），但平台返回“api scope is not declared in the privacy agreement”，意思是：这个API的使用权限没有在隐私协议里声明。

这跟Library没关系，是API调用时的权限策略问题。平台规定：一些敏感API（涉及相册、位置、通讯录等）不仅需要你调用时申请授权，还必须提前在平台后台配置好声明。属于“API提供方定的规则，调用方没遵守”。

排查思路：

• 去对应的开放平台，检查App/小程序的权限声明里是否包含了该API。
• 如果之前没配置，补上对应说明后重新发布或提交审核。
• 在代码里先检查API是否可用，再调用，这样用户体验会好很多。

这个场景能帮你理解：API的公开发布者有权决定“能用什么、不能用什么、怎么用”。你调用API时，必须遵守对方的规则，而不是像用Library那样随心所欲。

6.5 报错排查速查表

我把上面场景的排查要点整理成一张速查表，方便以后遇到问题直接对照定位：

这个表可以帮你在报错的第一时间大致判断问题方向。很多时候新手看到一个报错里有“library”就以为全是“库文件缺失”的问题，结果排查半天发现是API权限没开。先看报错关键字，再定位层面，效率会高很多。

7. 给新手的一些实操建议

概念都清楚了，最后分享几条我实际开发中总结出来的建议，尤其是针对刚接触SDK/API/Library的同学。

7.1 拿到SDK先跑Demo，别急着嵌入自己项目

很多人拿到一份SDK压缩包，第一反应是把头文件和库复制进自己的工程，然后开始写业务代码。这个习惯非常不好。

正确姿势是：先打开SDK自带的示例工程，原封不动跑一遍。确保环境、依赖、权限都没问题之后，再考虑集成。跑Demo的过程，本质上就是在验证SDK自身能不能正常工作，帮你先把“SDK坏了”这个变量排除掉，后面出问题才好排查。

7.2 接口报错先看状态码和错误信息，再去搜代码

遇到API调用失败，不要第一时间怀疑代码逻辑。先看请求返回的状态码和具体错误信息。400代表参数或请求格式不对，401/403代表认证或权限问题，429代表频率超限，500+代表服务端问题。不同的状态码，处理思路完全不同。

比如热词里那条“api error: 400 the supported api model names are deepseek-flash”——这是模型名称不支持，属于参数错误，不是你代码结构的问题。只要把模型名换成列表里支持的名称就行。

7.3 区分“SDK问题”和“API问题”是调试第一课

遇到一个与SDK、API相关的报错，先问自己三个问题：

• 这个报错发生在本地编译阶段吗？如果是，大概率是Library、工具链、环境变量的问题。
• 这个报错发生在运行阶段且跟网络有关吗？那大概率是API服务端、认证、限流的问题。
• 这个报错是说“找不到某个文件”吗？那大概率是SDK里某个库文件的路径或版本问题。

这三个问题问完，排查范围能缩小80%。很多新手卡在“到底是代码问题还是环境问题还是服务问题”这个环节上，白白浪费时间。

7.4 版本号是最容易忽略的“隐形杀手”

上面反复提到版本问题，这里必须单独拎出来强调一次。开发中最典型的连锁事故是这样的：

• 你按教程下载了某SDK的最新版，但教程是老版本，示例代码里调用的API签名变了。
• 你的主程序依赖某Library的动态库版本A，但系统PATH里恰好有版本B，运行时就加载到B了。
• 你在一个环境里装了好几个框架版本，某个库文件被误覆盖。

这些问题的共同特点就是：你的代码没变，但环境变了，然后一切开始出错。所以遇到诡异问题，先检查各种版本号：SDK版本、构建工具版本、运行时版本、依赖库版本。把它们列出来，跟官方文档对照一遍，很多时候会立刻发现问题。

7.5 善用官方文档和Demo，不要迷信博客教程

我理解新手上网搜教程是因为官方文档有时候不够“亲切”，语言绕、例子少。但博客教程最大的问题是有时效性，半年前的写法可能就已经过时了。

折中的办法是：第一手信息永远看官方文档，不懂的概念再看博客辅助理解。尤其是API的参数、SDK的配置步骤这种硬信息，一定以官方文档为准。这样能省掉大量“照着博客配完却跑不通”的烦恼。

最后，说点实在的

我个人在这条路上踩过最大的坑，就是刚开始分不清“API”和“SDK”的边界，导致排错时走了一大段弯路。后来想明白一个道理：这三者的边界，本质上是“封装层级”的边界。

Library封装的是“代码逻辑”，你把别人写好的代码拿进自己的程序里复用。 API封装的是“跨进程或跨服务的调用规则”，你在本地调用一个可能运行在别处的服务。 SDK封装的是“完整的开发体验”，它帮你把库、接口、协议、工具都协调好，让你面向业务直接开发。

以后只要看到一个新名词，先问一句：它是什么层面的封装？我是在调它、还是它在调我？是本地文件、还是远程服务？是单一能力、还是整套方案？把这几个问题想清楚了，再复杂的技术概念也不会把你绕晕。

有一次我帮朋友定位一个相机采集问题，他一口咬定是相机硬件故障，换了根线、换了台电脑还是不行。我过去看了一眼日志，发现是SDK动态库没加载成功，报错写着“library not found”。就是三秒钟的事。所以他后来跟我说，早知道就早点弄懂SDK和Library的区别，也不至于白折腾一整天。

你如果能把这三个词理解透，再去看那些“Android SDK下载失败”“DGL library not found”“API调用超限”之类的报错，至少能第一时间判断出问题出在哪个环节，不会一头扎进代码里瞎改。这才是这篇文章最想帮你解决的问题。