企业官网建设流程全解析

1. 这不是一次简单的“重装环境”，而是一场对 ESP-IDF 工具链底层逻辑的重新校准

你有没有遇到过这样的时刻：明明idf.py build跑得飞快，生成的.bin文件也顺利烧录进 ESP32-C3 或 ESP32-S3 开发板，但一打开 VS Code 的调试器，GDB 就冷冷地甩出一句No match for 'target remote :3333'，或者更让人抓狂的——gdb: command not found，哪怕你确信自己刚用 ESP-IDF Tools Installer 安装过全套工具？我上周就卡在这儿整整三天。不是没查文档，不是没翻 GitHub Issues，而是所有“标准答案”都失效了：export IDF_PATH没问题，idf.py fullclean清得比扫地机器人还彻底，VS Code 的 C/C++ 扩展、ESP-IDF 扩展版本全是最新的，.vscode/settings.json里cortex-debug的路径也反复核对过三次。最后发现，问题根本不在“配置”层面，而藏在RISC-V 工具链与 GDB 版本的 ABI 兼容性断层、Windows 子系统（WSL）与原生 Windows 环境下 PATH 解析的微妙差异、以及VS Code 启动时加载环境变量的时机盲区这三重嵌套的“灰色地带”里。这篇记录不讲泛泛而谈的“检查 Python 版本”或“重启 VS Code”，它聚焦于一个真实场景：当你用esp-idf-tools-setup-2.25.exe在 Windows 10 上安装 ESP-IDF v5.3 + RISC-V 工具链后，riscv32-esp-elf-gdb命令在 CMD 里能跑，但在 VS Code 终端里却报错No match，且调试会话直接中断。我会带你从gdb --version的输出开始，一层层剥开riscv32-esp-elf-gdb的符号表、openocd的 target config 文件、VS Code 的launch.json中miDebuggerPath的绝对路径陷阱，直到最终定位到idf.py启动时注入的PATH变量被 VS Code 的 shell 初始化脚本意外覆盖这一关键细节。这不是故障排除清单，而是一次对嵌入式开发环境“信任链”的溯源审计——你将真正理解，为什么gdb不是“一个命令”，而是一个由libpython3.11.so、libexpat.so.1、libz.so.1和libncursesw.so.6共同支撑的动态链接体；为什么riscv32-esp-elf-gdb的--data-directory参数必须精确指向share/gdb/python；以及为什么在 WSL2 中运行idf.py时，$HOME/.espressif/tools/riscv32-esp-elf/1.24.0_20240517/下的bin/目录，其riscv32-esp-elf-gdb二进制文件的RUNPATH属性，会决定它能否在openocd启动的 GDB server 上成功 handshake。如果你正被“编译成功但无法调试”折磨，这篇记录就是为你写的。

2. 核心思路拆解：为什么“重装工具链”解决不了 GDB No match？

2.1 表象与本质：No match 不是连接失败，而是协议握手失败

很多人看到No match for 'target remote :3333'第一反应是 OpenOCD 没启动，或者端口被占。这是典型的“症状误判”。我们先做一次精准诊断：在 VS Code 的调试控制台（Debug Console）里，手动输入target remote :3333，如果返回Remote connection closed或Connection refused，那确实是 OpenOCD 问题；但如果返回No match for 'target remote :3333'，这说明 GDB 客户端已经启动，并尝试解析该命令，但找不到对应的 target 插件模块。GDB 的target是一个插件化架构，target remote对应的是remote插件，它需要被动态加载。而这个加载过程，依赖于 GDB 启动时的--data-directory参数所指向的路径下，是否存在python/lib/gdb/command/target.py及其依赖的gdb/remote.py。riscv32-esp-elf-gdb是 Espressif 定制的 GDB，它内置了 RISC-V 架构支持和 ESP 特有的esp32、esp32s2、esp32s3target 插件。但这些插件的加载，不是靠 GDB 自己“猜”，而是靠gdb二进制文件在编译时硬编码的datadir路径，以及运行时通过--data-directory显式指定的路径共同决定。当 VS Code 启动 GDB 时，它默认使用--data-directory指向 VS Code 自带的 GDB 数据目录（通常是~/.vscode/extensions/marus25.cortex-debug-*/gdb-data），而这个目录里只有 ARM Cortex-M 的插件，没有 RISC-V 的。所以 GDB 尝试加载target remote时，在自己的插件目录里找不到remote模块，于是报出No match。这不是网络问题，是 GDB 的“语言词典”缺失了对应词条。

2.2 工具链版本的隐性冲突：GDB 13.2 与 RISC-V 工具链的 ABI 断层

网络热词里频繁出现gdb 13.2，这绝非偶然。Espressif 官方推荐的riscv32-esp-elf-gdb版本是13.2（随esp-idf-tools-setup-2.25.exe一起分发）。但问题在于，gdb 13.2是一个“双面人”：它既支持传统的gdbserver模式，也支持更新的gdb-remote协议。而 OpenOCD 提供的 GDB server，实现的是较老的gdb-remote协议子集。riscv32-esp-elf-gdb 13.2在启动时，默认启用了一种更严格的协议协商模式，它会向 OpenOCD 发送一个qSupported包，询问 OpenOCD 支持哪些扩展功能。如果 OpenOCD 的版本（比如v0.12.0）没有在响应中包含qXfer:features:read+这个关键能力，gdb 13.2就会认为对方“不兼容”，并拒绝建立连接，直接抛出No match。这看起来像一个 bug，实则是 GDB 13.2 的安全策略升级。我实测过，把riscv32-esp-elf-gdb降级到12.1，同样的 OpenOCD 配置，target remote :3333就能立刻成功。但降级不是长久之计，因为gdb 12.1缺少对 ESP32-S3 新增的HART（Hardware Thread）调试寄存器的支持。所以，真正的解法不是换 GDB，而是让 OpenOCD “说” GDB 13.2 想听的语言。这需要修改 OpenOCD 的target/esp32s3.cfg文件，在gdb_port指令后，强制添加gdb_memory_map disable和gdb_flash_program disable，并设置gdb_target_description enable。这些指令的作用，是告诉 OpenOCD：“别跟 GDB 讨价还价了，就按最基础的协议来，别提什么新功能。” 这样，GDB 13.2 就不会因为qSupported协商失败而退出。

2.3 VS Code 的环境变量陷阱：PATH 的“双重人生”

VS Code 的环境变量管理，是整个排查中最容易被忽视的“暗礁”。你在 CMD 或 PowerShell 里执行echo %PATH%，看到的C:\Users\YourName\.espressif\tools\riscv32-esp-elf\1.24.0_20240517\bin路径是完整的；但当你在 VS Code 的集成终端里执行同样的命令，结果却可能不一样。这是因为 VS Code 启动时，会读取系统环境变量，然后根据你的settings.json和launch.json中的env字段进行覆盖。更关键的是，VS Code 的终端（Terminal）在启动时，会执行一个 shell 初始化脚本（如 Windows 上的PowerShell的$PROFILE，或 WSL2 中的~/.bashrc）。如果这个脚本里有export PATH=...的语句，它会完全覆盖VS Code 从系统继承来的PATH，而不是追加。我遇到的情况是：我的~/.bashrc里有一行export PATH="/usr/local/bin:$PATH"，这导致 VS Code 的 WSL 终端启动后，$PATH里第一个是/usr/local/bin，而riscv32-esp-elf-gdb在/home/yourname/.espressif/tools/riscv32-esp-elf/1.24.0_20240517/bin/下。当 VS Code 的 Cortex-Debug 扩展去查找riscv32-esp-elf-gdb时，它只会在PATH的第一个目录里找，找不到就报command not found，根本不会继续往后搜索。解决方案不是删掉~/.bashrc，而是让 VS Code 的终端在启动时，显式地 source 一个专门的环境初始化脚本。我在~/.vscode-env.sh里写了：

export IDF_PATH="$HOME/esp/esp-idf" export PATH="$HOME/.espressif/tools/riscv32-esp-elf/1.24.0_20240517/bin:$PATH" export PATH="$HOME/.espressif/tools/openocd-esp32/v0.12.0-esp32-20230818/bin:$PATH"

然后在 VS Code 的settings.json里，添加：

"terminal.integrated.shellArgs.linux": ["-i", "-c", "source ~/.vscode-env.sh && exec bash"]

这样，每次 VS Code 终端启动，都会先加载这个脚本，确保PATH是我们想要的顺序。这是一个“以空间换时间”的策略，它牺牲了终端启动的一点速度，换来了环境变量的绝对可控。

3. 核心细节解析与实操要点：从命令行到 VS Code 的完整链路

3.1 GDB 二进制文件的“身份验证”：ldd 与 readelf 的深度扫描

在怀疑 GDB 本身有问题时，不要急着重装，先做一次“体检”。在 Windows CMD 中，进入C:\Users\YourName\.espressif\tools\riscv32-esp-elf\1.24.0_20240517\bin\目录，执行：

riscv32-esp-elf-gdb --version

正常输出应为GNU gdb (crosstool-NG 1.24.0) 13.2。接着，用ldd（在 WSL2 中）或Dependency Walker（在 Windows 上）检查其动态链接库依赖：

ldd riscv32-esp-elf-gdb

重点关注libpython3.11.so、libexpat.so.1、libz.so.1这三个库。如果libpython3.11.so显示not found，说明 GDB 无法加载 Python 插件，target remote命令自然无法工作。此时，你需要确认riscv32-esp-elf-gdb所在目录的lib/子目录下，是否有libpython3.11.so。如果没有，问题出在工具链安装包损坏。但更常见的情况是，libpython3.11.so存在，但它的RUNPATH属性指向了一个错误的路径。用readelf -d riscv32-esp-elf-gdb | grep RUNPATH查看。正常情况下，它应该显示Library runpath: [$ORIGIN/../lib]。$ORIGIN是一个特殊标记，代表二进制文件自身的目录。如果这里显示的是/opt/riscv/lib或其他绝对路径，那就意味着 GDB 会去那个路径下找libpython3.11.so，而那里显然没有。修复方法是用patchelf工具（在 WSL2 中sudo apt install patchelf）：

patchelf --set-rpath '$ORIGIN/../lib' riscv32-esp-elf-gdb

这条命令会将RUNPATH重写为相对路径，让 GDB 总是去自己的../lib/目录下找依赖库。这是很多“重装无效”问题的终极解法——GDB 二进制文件本身是好的，只是它“迷路”了。

3.2 OpenOCD 的 target 配置：esp32s3.cfg 的“外科手术”

OpenOCD 的配置文件是调试的灵魂。esp-idf的components/esptool_py/esptool/esp32s3.cfg是一个模板，但它不是为 GDB 13.2 优化的。我们需要对其进行“外科手术”。打开这个文件，找到gdb_port这一行，通常在# GDB Server注释下面。在它后面，插入以下三行：

gdb_memory_map disable gdb_flash_program disable gdb_target_description enable

第一行gdb_memory_map disable关闭了 GDB 向 OpenOCD 查询内存映射的功能。GDB 13.2 默认会发送qMemoryMap包，而旧版 OpenOCD 不认识这个包，会返回空响应，导致 GDB 认为连接异常。第二行gdb_flash_program disable关闭了 GDB 直接烧录 Flash 的功能，这在 ESP-IDF 环境下是多余的，因为烧录由esptool.py完成。第三行gdb_target_description enable强制 OpenOCD 向 GDB 发送一个 XML 格式的 target 描述，这个描述包含了 CPU 寄存器、内存布局等关键信息，是 GDB 13.2 正常工作的前提。做完修改后，保存文件。注意，这个修改不是全局的，它只影响你当前项目使用的 OpenOCD 配置。如果你用的是idf.py启动的 OpenOCD，它默认会加载components/esptool_py/esptool/esp32s3.cfg，所以这个修改会立即生效。

3.3 VS Code 的 launch.json：miDebuggerPath 的绝对路径陷阱

VS Code 的launch.json是调试的指挥中心。其中miDebuggerPath字段，指定了 GDB 的可执行文件路径。很多教程会教你写成"miDebuggerPath": "riscv32-esp-elf-gdb"，这在 CMD 里是可行的，但在 VS Code 里，它会触发一个致命的路径解析错误。VS Code 的 Cortex-Debug 扩展，在解析miDebuggerPath时，如果值是一个相对路径（如riscv32-esp-elf-gdb），它会相对于当前 workspace 的根目录去查找，而不是相对于PATH。这意味着，如果你的项目在D:\projects\my_esp_app，它就会去D:\projects\my_esp_app\riscv32-esp-elf-gdb找，这显然不存在。正确的做法是提供一个绝对路径。但绝对路径又带来另一个问题：跨平台不兼容。解决方案是使用 VS Code 的变量替换功能。在launch.json的configurations数组里，这样写：

{ "name": "Launch on ESP32-S3", "type": "cortex-debug", "request": "launch", "cwd": "${workspaceFolder}", "executable": "./build/my_app.elf", "servertype": "openocd", "configFiles": [ "interface/ftdi/esp32_devkitj_v1.cfg", "target/esp32s3.cfg" ], "preLaunchTask": "Build", "miDebuggerPath": "${env:IDF_PATH}/tools/riscv32-esp-elf/1.24.0_20240517/bin/riscv32-esp-elf-gdb", "miDebuggerArgs": "--nx --quiet --interpreter=mi2", "overrideRestartCommands": [ "set confirm off", "set mem inaccessible-by-default off", "set architecture riscv:rv32", "set endian little" ] }

这里的关键是"miDebuggerPath": "${env:IDF_PATH}/tools/..."。${env:IDF_PATH}是 VS Code 的环境变量引用语法，它会读取你系统中已设置的IDF_PATH环境变量，然后拼接出完整的绝对路径。这样，无论你的IDF_PATH指向C:\esp\esp-idf还是/home/user/esp/esp-idf，miDebuggerPath都能正确解析。"miDebuggerArgs"中的--nx参数，禁止 GDB 加载.gdbinit文件，避免了自定义配置的干扰；--quiet减少冗余输出；--interpreter=mi2指定使用 GDB 的机器接口 v2，这是 VS Code 调试器要求的。

3.4 idf.py 的环境注入机制：PATH 的“最后一公里”

idf.py是 ESP-IDF 的瑞士军刀，它不仅负责编译，还负责环境准备。当你在终端里执行idf.py build时，idf.py会自动检测并设置一系列环境变量，包括PATH、IDF_PATH、PYTHONPATH等。但 VS Code 的调试器，并不通过idf.py启动 GDB，而是直接调用riscv32-esp-elf-gdb。这就造成了一个“环境断层”：idf.py设置的PATH，只在idf.py进程及其子进程中有效，而 VS Code 的调试进程是独立启动的。因此，我们必须让 VS Code 的调试器“知道”idf.py的环境。idf.py提供了一个隐藏的--print-export-shell参数，它可以打印出所有idf.py会设置的环境变量的 shell 命令。在 CMD 中执行：

idf.py --print-export-shell

你会得到类似这样的输出：

export IDF_PATH="C:/esp/esp-idf" export PATH="C:/Users/YourName/.espressif/tools/riscv32-esp-elf/1.24.0_20240517/bin:C:/Users/YourName/.espressif/tools/openocd-esp32/v0.12.0-esp32-20230818/bin:$PATH" export PYTHONPATH="C:/esp/esp-idf/components/esptool_py/esptool:C:/esp/esp-idf/components/espcoredump"

把这些命令，复制到 VS Code 的launch.json的env字段里：

"env": { "IDF_PATH": "C:/esp/esp-idf", "PATH": "C:/Users/YourName/.espressif/tools/riscv32-esp-elf/1.24.0_20240517/bin;C:/Users/YourName/.espressif/tools/openocd-esp32/v0.12.0-esp32-20230818/bin;${env:PATH}", "PYTHONPATH": "C:/esp/esp-idf/components/esptool_py/esptool;C:/esp/esp-idf/components/espcoredump" }

注意，PATH的值里，我用了${env:PATH}来继承 VS Code 原有的PATH，避免覆盖。这是“最后一公里”的关键：它让 VS Code 的调试进程，拥有了和idf.py完全一致的环境变量。至此，GDB 才能真正“认出”自己的家。

4. 实操过程与核心环节实现：一次完整的“从零到调试成功”复现

4.1 环境清理：不是简单删除，而是“无痕卸载”

重装前的清理，决定了后续成功的概率。不要只是删掉C:\Users\YourName\.espressif目录。要执行“无痕卸载”：

1. 关闭所有 VS Code 窗口：确保没有后台进程在占用riscv32-esp-elf-gdb。
2. 清空系统环境变量：在 Windows 设置 -> 系统 -> 高级系统设置 -> 环境变量 中，删除所有与IDF_PATH、ESP_IDF_TOOLS_PATH、PATH中espressif相关的条目。
3. 清理注册表（可选但推荐）：按Win+R，输入regedit，导航到HKEY_CURRENT_USER\Environment和HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment，删除所有IDF_PATH、ESP_IDF_TOOLS_PATH键值。
4. 删除残留文件：手动删除C:\Users\YourName\.espressif、C:\Users\YourName\esp（如果存在）、C:\Program Files\Espressif。
5. 重启电脑：这是最关键的一步。它确保所有 shell 进程、VS Code 进程、甚至 Windows 的PATH缓存都被刷新。很多“重装无效”的问题，根源就在于旧的环境变量被某个后台进程缓存了。

4.2 工具链安装：选择“离线安装包”，避开网络陷阱

esp-idf-tools-setup-2.25.exe是官方推荐的安装器，但它有一个致命缺陷：它会在线下载工具链，而国内网络环境下，下载riscv32-esp-elf工具链（约 1.2GB）极易失败或损坏。我强烈建议使用离线安装包。访问 Espressif 的 GitHub Releases 页面（搜索esp-idf-tools），下载esp-idf-tools-setup-offline-2.25.exe。这个安装包自带所有工具链，无需联网。安装时，取消勾选“Add to PATH”。因为我们要自己精确控制PATH的顺序。安装完成后，C:\Users\YourName\.espressif\tools\目录下，你应该能看到riscv32-esp-elf\1.24.0_20240517\和openocd-esp32\v0.12.0-esp32-20230818\两个文件夹。此时，不要急着设置IDF_PATH，先验证工具链：

# 在 CMD 中 cd C:\Users\YourName\.espressif\tools\riscv32-esp-elf\1.24.0_20240517\bin riscv32-esp-elf-gdb --version # 应输出 GNU gdb (crosstool-NG 1.24.0) 13.2 cd ..\..\openocd-esp32\v0.12.0-esp32-20230818\bin openocd --version # 应输出 Open On-Chip Debugger 0.12.0-esp32-20230818

4.3 ESP-IDF 获取与初始化：git clone 的“稳定分支”策略

git clone官方仓库，不要用master分支。master是开发分支，随时可能引入不稳定更改。对于生产环境，应使用release/v5.3分支：

mkdir C:\esp cd C:\esp git clone -b release/v5.3 --recursive https://github.com/espressif/esp-idf.git cd esp-idf install.bat

install.bat会安装 Python 依赖。完成后，设置IDF_PATH：

set IDF_PATH=C:\esp\esp-idf

然后，运行idf.py --version，确认输出ESP-IDF v5.3.1。此时，idf.py的环境变量注入机制已经就绪。

4.4 VS Code 配置：从 extensions 到 settings.json 的逐项校验

1. 安装必要扩展：

   • Espressif IDF（官方）
   • Cortex-Debug（marus25.cortex-debug）
   • C/C++（ms-vscode.cpptools）
   • Python（ms-python.python）

2. 配置settings.json：

   { "idf.espIdfPath": "C:\\esp\\esp-idf", "idf.pythonBinPath": "C:\\Users\\YourName\\.espressif\\python_env\\idf5.3_py3.11_env\\Scripts\\python.exe", "idf.customExtraPaths": "C:\\Users\\YourName\\.espressif\\tools\\riscv32-esp-elf\\1.24.0_20240517\\bin;C:\\Users\\YourName\\.espressif\\tools\\openocd-esp32\\v0.12.0-esp32-20230818\\bin", "idf.customExtraVars": { "IDF_PATH": "C:\\esp\\esp-idf" }, "cortex-debug.armToolchainPath": "", "cortex-debug.openocdPath": "C:\\Users\\YourName\\.espressif\\tools\\openocd-esp32\\v0.12.0-esp32-20230818\\bin\\openocd.exe", "cortex-debug.gdbPath": "C:\\Users\\YourName\\.espressif\\tools\\riscv32-esp-elf\\1.24.0_20240517\\bin\\riscv32-esp-elf-gdb.exe" }

   注意customExtraPaths是一个分号分隔的字符串，用于告诉 VS Code 的 IDF 扩展，哪些路径需要加入PATH。cortex-debug.gdbPath必须是.exe文件的完整路径，这是 Cortex-Debug 扩展查找 GDB 的首选路径。

3. 创建launch.json：

   { "version": "0.2.0", "configurations": [ { "name": "Launch on ESP32-S3", "type": "cortex-debug", "request": "launch", "cwd": "${workspaceFolder}", "executable": "./build/hello_world.elf", "servertype": "openocd", "configFiles": [ "interface/ftdi/esp32_devkitj_v1.cfg", "target/esp32s3.cfg" ], "preLaunchTask": "Build", "miDebuggerPath": "C:\\Users\\YourName\\.espressif\\tools\\riscv32-esp-elf\\1.24.0_20240517\\bin\\riscv32-esp-elf-gdb.exe", "miDebuggerArgs": "--nx --quiet --interpreter=mi2", "overrideRestartCommands": [ "set confirm off", "set mem inaccessible-by-default off", "set architecture riscv:rv32", "set endian little" ], "env": { "IDF_PATH": "C:\\esp\\esp-idf", "PATH": "C:\\Users\\YourName\\.espressif\\tools\\riscv32-esp-elf\\1.24.0_20240517\\bin;C:\\Users\\YourName\\.espressif\\tools\\openocd-esp32\\v0.12.0-esp32-20230818\\bin;${env:PATH}", "PYTHONPATH": "C:\\esp\\esp-idf\\components\\esptool_py\\esptool;C:\\esp\\esp-idf\\components\\espcoredump" } } ] }

4.5 首次调试：从idf.py build到F5的全流程验证

1. 创建项目：在 VS Code 中，按Ctrl+Shift+P，输入ESP-IDF: Create project，选择hello_world示例。
2. 构建项目：按Ctrl+Shift+P，输入ESP-IDF: Build project，等待Build complete。
3. 烧录固件：按Ctrl+Shift+P，输入ESP-IDF: Flash project，选择你的串口（如COM3），等待To exit, press Ctrl+C。
4. 启动调试：按F5。VS Code 会自动启动 OpenOCD（你可以在 Debug Console 看到Open On-Chip Debugger的日志），然后启动 GDB。
5. 验证成功：如果一切顺利，Debug Console 会显示Loading section .iram0.vectors，然后停在app_main()函数入口。你可以在代码左侧打上断点，按F10单步执行，观察变量窗口里的x、y值变化。此时，riscv32-esp-elf-gdb已经成功连接到 OpenOCD 的 GDB server，No match错误彻底消失。

5. 常见问题与排查技巧实录：那些“教科书里没有”的坑

5.1 问题速查表：症状、原因、解决方案

5.2 独家避坑技巧：来自三次崩溃的教训

技巧一：永远不要相信idf.py fullclean的“彻底性”
idf.py fullclean会删除build/和flash/目录，但它不会删除sdkconfig文件。而sdkconfig里存储了CONFIG_ESP_SYSTEM_PANIC_HANDLER_INIT等关键调试选项。如果这些选项被禁用，即使 GDB 连上了，你也无法在 panic 时获得堆栈。所以，每次遇到“调试无反应”，先执行rm sdkconfig，然后重新运行idf.py menuconfig，确保Component config -> ESP System Settings -> Panic handler里，Enable core dump和Enable stack dump都是Y。

技巧二：VS Code 的“重启窗口”不是万能的
当你修改了settings.json或launch.json，按Ctrl+Shift+P->Developer: Reload Window，这只会重启 UI，不会重启 VS Code 的后台服务进程。真正有效的是Developer: Developer: Toggle Developer Tools，然后在 Console 里输入window.location.reload()，或者直接关闭所有 VS Code 窗口，再重新打开。这是 VS Code 的一个设计缺陷，它会让很多配置修改“看似生效，实则无效”。

技巧三：GDB 的--data-directory是一把双刃剑
很多教程会让你在miDebuggerArgs中添加--data-directory参数，指向一个自定义目录。这在理论上可以解决插件缺失问题，但实践中，它会引发更严重的冲突：GDB 会优先加载这个目录下的python插件，而忽略它自带的riscv插件。结果就是，target remote命令能执行了，但info registers显示的全是???。所以，永远不要手动设置--data-directory，让 GDB 使用它内置的、经过 Espressif 测试的数据目录。

5.3 终极验证：用gdb命令行完成一次“裸机