Windows服务从入门到故障排查：本质、命令与优化实践

“Windows服务”这四个字，很多Windows用户和运维新手都见过，但真正搞清楚它是什么、怎么管、出了故障往哪查的人并不多。我经常在社区里看到这样的问题：装了个软件后服务启动失败、Windows Update怎么也修不好、游戏卡顿想关后台服务又不敢乱关、远程桌面突然连不上……这些问题，十个里有八个最后都能追溯到服务本身。

这篇内容就从Windows服务的基础认知说起，不端着、不绕弯，把服务的本质、启动机制、管理命令、故障排查讲清楚，最后落到实际应用——游戏优化、MySQL部署、远程桌面配置。没系统学过Windows管理的朋友也能跟上，已经有一定基础的人也能从故障案例里拿到一些排查思路。

1. Windows服务的本质：它和普通程序到底差在哪

1.1 服务是“没有桌面的后台程序”

从概念上讲，Windows服务就是一种特殊的可执行程序，特殊在它由“服务控制管理器”（SCM，Service Control Manager）统一管理。SCM是Windows内部的核心组件，负责服务的注册、启动、停止和状态跟踪。你在services.msc里看到的每一个服务，背后都归它调度。

和普通程序最大的差别是：普通程序是你双击或命令行启动的，跟着你的登录会话走；服务则不需要任何用户登录就能运行。比如Windows Update服务，你在登录界面前它可能就已经在跑；打印后台处理、DNS客户端、Windows防火墙这些，都是在用户还没登录到桌面时就开始工作了。

从Windows Vista开始，服务被隔离在“会话0”中。早期Windows里服务线程可以直接往用户桌面弹窗，结果就是正用着Word突然冒出一个服务的错误对话框，点也不是不点也不是。会话0隔离之后，服务和普通用户程序分属不同会话，服务无法直接访问你的桌面。这也是为什么很多服务即使有界面，你也看不到——它们活在另一个“房间”里，互不干扰。

这个区别非常重要，它解释了一个常见误区：很多人以为“服务就是一个后台程序，关了就关了”。其实服务是系统级任务，不是普通进程。你结束一个普通程序，只影响你自己；你结束一个系统服务，可能影响所有用户、网络功能，甚至整个系统的运行。

1.2 为什么任务管理器里全是svchost.exe

打开任务管理器，看到一堆svchost.exe，这是新手最容易困惑的地方。svchost.exe本身只是个宿主进程，真正干活的是几十个跑在它里面的服务。

微软在XP之后开始做服务合并，目的是减少进程数量和内存占用。服务被按功能分组，比如netsvcs组里挂了一堆网络相关服务，每个svchost进程对应一个服务组，组内服务共享同一个进程地址空间。所以你看到的几十个svchost进程，并不是重复的系统垃圾，而是不同服务组的“容器”。

要查看某个svchost里到底跑了哪些服务，很多人不知道，其实很简单。在services.msc里双击任意服务，切到“依存关系”标签页，能看它和其他服务的关联；命令行方式更直接，用tasklist自带的svc选项：

code复制tasklist /svc | findstr /i svchost

这个命令会列出每个svchost进程PID对应的具体服务名。想看得更清楚，还可以用PowerShell：

code复制Get-CimInstance Win32_Service | Where-Object {$_.PathName -like '*svchost*'} | Select-Object Name, State, ProcessId

这个知识点在排查问题时极其有用。比如某个svchost进程CPU突然飙高，你需要在任务管理器里定位是哪个PID，然后反查它里面挂了哪些服务，命中的服务就是嫌疑人。没有这层认知，看到几十个svchost只会一脸懵。

1.3 服务账户：服务到底以谁的“身份”在跑

服务的运行身份，我用一个生活化比喻：普通程序是“你自己的分身”，服务则是“系统安排的工作人员”。Windows给服务准备了几种内置身份，它们的权限完全不同。

在services.msc里双击一个服务，切到“登录”标签页，会看到服务可以以“本地系统账户”“网络服务账户”“本地服务账户”运行，也可以指定一个特定账户。千万不要图省事给服务填个管理员密码，很多安全隐患就是这样搞出来的。

排查服务权限问题时，重点关注两步：第一，这个服务以什么身份运行；第二，这个身份对它要访问的文件/注册表有没有权限。很多服务启动报“拒绝访问”，是权限问题，而不是文件损坏。理解了服务身份，才不会在排查时南辕北辙。

2. 服务的启动生命周期：懂这层才敢动服务

2.1 启动类型：自动、延迟自动、手动、禁用，到底怎么选

服务启动类型有四种，很多人只看到services.msc里那几个选项，容易忽略“延迟启动”的价值。

• 自动（Automatic）：开机时由SCM自动启动，适合核心服务。
• 自动（延迟启动）（Automatic Delayed Start）：开机后先让其他服务跑起来，稍等一段时间再启动。这个设计是为了错峰，减少开机资源竞争。对性能敏感的人，可以把不紧急但需要长期运行的服务设置为延迟自动。
• 手动（Manual）：不主动启动，按需启动。但手动并不等于“不用它”——当其他服务依赖它，或者有触发器事件时，它照样会启动。
• 禁用（Disabled）：SCM不会启动它，也不能被依赖服务拉起。这是最激进的选项，也是最容易出问题的选项。

这里有个典型误区：有人为了给游戏腾资源，把一堆服务设为手动，甚至“看着没用的就禁用”。等你下次用某个功能，服务起不来，排错半天才发现是自己禁用的。

从注册表看更清楚：HKLM\SYSTEM\CurrentControlSet\Services<服务名> 下的Start键值，0表示Boot，1表示System，2表示Auto，3表示Manual，4表示Disabled。前两个一般是驱动级别，普通服务基本不会用到0和1。当你手动把服务改成“自动”后，注册表里的Start值会变成2；改手动变成3；禁用变成4。

如果某个服务无论你怎么改，重启后又变回禁用，那大概率是组策略在接管，或者服务本身的配置被安全软件锁定了。这个现象在Windows Update上非常常见，后面会展开细讲。

2.2 依赖关系：启动一个服务，为什么带出一串

服务依赖是Windows服务体系里最容易被忽略的部分。你可以把服务之间的依赖看成“建筑的承重墙”：一面墙倒了，整层楼都受影响。

用命令查看依赖最直观：

code复制sc qc wuauserv

输出里会有一行DEPENDENCIES，列出这个服务依赖谁。反过来，想知道谁依赖它，用：

code复制sc enumdepend wuauserv

这个命令在做服务优化时极其重要——你关掉一个看似没用的服务，结果它下游还有一堆服务要用它，就会引发连锁故障。

举几个热搜词里直接相关的例子：

• Windows Update（wuauserv）依赖Remote Procedure Call（RPC）和DCOM Server Process Launcher。RPC这个服务几乎全系统都在用，想关掉RPC等于让Windows半身不遂，千万别碰。
• IIS网站服务的W3SVC和WAS是两个强依赖。热搜词里“除非Windows Activation Service(WAS)和万维网发布服务(W3SVC)均处于运行状态”，就是IIS站点启动时报的经典错误。很多人为了“优化系统”把W3SVC禁了，下次访问本地网站直接打不开，排查半天才发现服务没起来。
• Windows Installer（msiserver）依赖RPC。如果你用某些工具把RPC设置为禁用，MSI安装包全部罢工。

所以在动任何服务之前，建议先花十秒钟查一下依赖关系。这个习惯能省下一整夜排错时间。

2.3 恢复选项：服务崩溃后系统会干什么

services.msc里第三个标签页“恢复”很少有人点开，但这个页面在排查“服务为什么一直重启”时非常关键。

恢复选项可以配置这样几项：

• 第一次失败时：不操作、重新启动服务、运行一个程序、重新启动计算机。
• 第二次失败时：同上三选。
• 后续失败时：同上。
• 重置失败计数的时间：默认是1天。
• 重新启动服务的时间：默认1分钟。

这里有一个容易踩的坑：如果某个服务的恢复策略设置成“重新启动服务”，服务崩溃后SCM会把它拉起来；但如果这个服务属于启动即崩溃的类型，就会陷入“起不来-重启-再起不来-再重启”的循环，CPU被反复占满、事件日志疯狂报错。很多用户以为是中毒了，其实是恢复策略加启动即崩的组合结果。

正确排查做法：先看事件查看器里服务崩溃时的错误代码，再确认恢复策略，最后把恢复策略临时改成“不操作”，让服务保持崩溃状态，方便抓现场证据。等修复了文件或配置，再恢复原来的策略。

3. 实操命令与隐藏入口：services.msc之外的效率武器

3.1 services.msc：除了启停，这4个地方用得少但很有用

services.msc大概是Windows自带工具里被用得最多又用得最浅的一个。双击一个服务，除了“启动/停止/重启”三个按钮和启动类型下拉框，还有几块隐蔽且实用的区域。

第一，“登录”标签可以调整服务账户。跨域部署、给服务指定托管账户，都在这里改。改的时候服务管理器会自动更新相关权限，比手动改注册表安全。

第二，“恢复”标签页上面已经讲过，不再重复。

第三，“依存关系”标签页非常实用。它分两个列表：“此服务依赖以下系统组件”和“以下系统组件依赖此服务”。在排查连接不上、功能异常时，这里比网上搜到的通用教程更靠谱，因为它显示的是你当前这台机器的实际依赖关系，不会骗你。

第四，服务列表的列是可以自定义的。在空白处右键“选择列”，把“PID”“服务类型”“路径”等列显示出来，定位问题会快很多。比如看到某个svchost进程CPU爆高，你可以直接在服务列表里按PID列排序，找出对应服务。

3.2 sc命令：写脚本、批量改启动类型的标准姿势

services.msc适合单次操作，批量修改、自动化脚本、远程管理，还是sc命令更靠谱。

查询服务和配置服务的常用命令：

code复制sc query 服务名
sc qc 服务名
sc config 服务名 start= auto
sc config 服务名 start= demand
sc config 服务名 start= disabled
sc start 服务名
sc stop 服务名

注意：sc config的start=后面必须有个空格，否则报错。这个坑我在写批处理时踩过很多次，命令格式看起来一样，就差一个空格，结果死活不生效。

查询所有服务：

code复制sc query state= all
sc query state= all | findstr /i "SERVICE_NAME STATE"

批量操作时可以用for循环。但禁止干“把一批看着没用的服务全部禁用”这种事，稍后会举例说明哪些服务不能乱动。更合理的批量场景是：先查询某个svchost进程组里的服务名，再统一启停。

还有一个不太常见但很实用的sc子命令：sc sdshow可以查看服务的安全描述符，sc sdset可以修改。企业级安全基线、想做服务级权限收敛时，会用到这个。

3.3 PowerShell与注册表：更细的“上帝视角”

PowerShell对服务的操作能力比sc更强，因为可以直接拿到对象，管道组合非常方便。

查看服务列表：

code复制Get-Service
Get-Service -Name wuauserv

查看启动类型和账户信息，需要走CIM：

code复制Get-CimInstance Win32_Service -Filter "Name='wuauserv'" | Select-Object Name, StartMode, StartName

修改启动类型：

code复制Set-Service -Name wuauserv -StartupType Manual

批量操作示例：找出所有启动类型为自动、但状态为停止的服务：

code复制Get-CimInstance Win32_Service | Where-Object {$_.StartMode -eq 'Auto' -and $_.State -eq 'Stopped'} | Select-Object Name, DisplayName

这类命令在做系统诊断时非常有用。想知道系统里哪些服务“本该启动却没起来”，一查便知。

注册表也不可忽略。服务的完整配置存在HKLM\SYSTEM\CurrentControlSet\Services\下，每个服务一个子键。除了Start、ImagePath、ObjectName、DependOnService之外，还有很多高级参数服务自己会写在这里。当你用sc或services.msc改不生效时，检查注册表子键的权限、看看是不是被组策略覆盖，通常能找到答案。但正常管理服务不要直接改注册表，优先用sc或服务管理器，注册表是排查手段，不是第一修改入口。

4. 热搜故障拆解：服务起不来的几类典型原因与排查链路

4.1 错误126“找不到指定的模块”：Windows Update的经典翻车

热搜词里有一条很典型：“Windows无法启动Windows Update服务位于本地计算机上，错误126：找不到指定的模块。”错误126的意思是系统尝试加载某个DLL或驱动时，文件不存在、依赖模块缺失，或者路径不对。

Windows Update服务（wuauserv）的实际ImagePath是：

code复制C:\Windows\System32\svchost.exe -k netsvcs -p

它真正的业务实现是C:\Windows\System32\wuaueng.dll。这个DLL如果被安全软件、清理工具误删，或者系统文件损坏，就会报126。

我建议按这个顺序排查：

1. 先确认服务配置没被动过。

   code复制sc qc wuauserv
   

   看BINARY_PATH_NAME和START_TYPE是否正常。

2. 检查依赖服务。wuauserv依赖RPC和DcomLaunch，这俩状态不对，先修它们。

3. 检查wuaueng.dll是否存在。

   code复制Test-Path C:\Windows\System32\wuaueng.dll
   

   不存在就基本实锤是文件丢了。

4. 用系统文件检查器修复。

   code复制sfc /scannow
   

   sfc搞不定，再用DISM：

   code复制DISM /Online /Cleanup-Image /RestoreHealth
   

   sfc负责修复系统文件，DISM负责修复系统映像，顺序不能反。

热搜词里还有一条“Windows更新无法在服务中改成自动”，这多半是组策略或注册表策略锁定了更新状态。去组策略编辑器里看“计算机配置→管理模板→Windows组件→Windows Update”相关策略，或者看系统更新设置里的“暂停更新”是否开启。如果都不是，检查wuauserv注册表项的权限是不是被改成拒绝写入了。

顺便提一句，网上有些“优化脚本”会把Windows Update服务禁用，结果系统安全补丁装不上，过几个月系统越来越慢还不知道为什么。Windows Update服务你可以设成手动，但最好别长期禁用。

4.2 Windows Installer服务离奇消失：别急着重装系统

“Windows Installer服务没找到”这个热搜词很常见。msiserver服务不见了，结果任何.msi安装包都装不了，网上很多建议是重装系统，其实大部分情况能救回来。

先确认状态：

code复制sc query msiserver

如果返回“指定的服务未安装”，说明服务注册表项都没了。常见原因：某些卸载软件彻底清理时误删服务，或者系统优化工具禁用了它又清理过头。

修复思路：

1. 注册服务。以管理员身份运行：

   code复制msiexec /unregister
   msiexec /regserver
   

   也可以先执行msiexec /regserver两次，这个命令会重新注册Windows Installer的相关组件，服务条目也会被重建。

2. 如果上面不管用，手动创建服务：

   code复制sc create msiserver type= own start= demand binPath= C:\Windows\System32\msiexec.exe /V
   

   注意binPath里的空格，引号要小心。手动建完后再测试安装MSI。

3. 还不行就检查msi.dll是否损坏，重新注册：

   code复制regsvr32 msi.dll
   regsvr32 msiexec.exe
   

多数情况到这一步就解决了。这案例的启发是：服务本质上是一组注册表配置加一个可执行文件路径。只要找到正确的路径和参数，sc create能手动“造”回一个服务。理解了这个机制，类似的“服务丢失”问题都能按同一套路救回来。

4.3 wmiaprpl.dll报错与WmiApRpl服务：看着吓人，其实多半无伤大雅

热搜词里有一条看起来特别奇怪的：

asdadwdll“c:\windows\system32\wbem\wmiaprpl.dll”中“wmiaprpl”服务的open...

这背后是WmiApRpl服务，全称WMI Performance Adapter。这个服务的作用是提供WMI性能数据的适配，默认手动启动。很多机器上它处于停止状态，但在某些软件或性能监控组件尝试调用它时，如果wmiaprpl.dll文件损坏或权限不对，就会在事件日志里报错。

根据我的经验，这个服务对绝大多数普通用户来说并不重要，保持禁用也不影响日常使用。但如果错误日志刷屏让你心烦，建议这样处理：

1. 先确认它是WmiApRpl而不是WmiApSrv。WmiApSrv是核心WMI服务，那个不能乱动。两个名字很像，千万别搞混。

2. 检查文件是否存在。

   code复制Test-Path C:\Windows\System32\wbem\wmiaprpl.dll
   

3. 文件丢失或损坏就修复系统文件。

   code复制sfc /scannow
   

4. 如果确认不需要这个性能适配功能，可以在services.msc里把WmiApRpl设为禁用。禁用后错误消失即可，不用过度纠结。

这类“报错但影响不大”的服务有很多。关键是要分清哪些是核心、哪些是外围。核心服务出问题必须修，外围服务出问题，可以先评估是否需要，再决定修还是禁。

4.4 启动失败577：驱动签名校验没通过

热搜词里“正在启动 simplesvm 服务... [sc] startservice 失败 577: windows 无法验证此文”非常典型。577对应系统错误码ERROR_INVALID_IMAGE_HASH，翻译过来就是：Windows在加载这个驱动或服务时，验证数字签名不通过。

这个错误通常出现在这样几个场景：

• 服务指向的驱动文件是旧的、未签名的第三方驱动，Windows安全机制拒绝加载。
• 文件被篡改或部分损坏，签名校验失败。
• 系统开启了“内存完整性”（内核隔离的一部分），对驱动签名要求更严格。

排查链路：

1. 找出simplesvm服务对应的可执行文件路径。

   code复制sc qc simplesvm
   

   看BINARY_PATH_NAME指向什么驱动或exe。

2. 用右键属性里的“数字签名”标签查看文件签名。没有签名或签名者是陌生厂商，大概率就是这个问题。

3. 如果是第三方驱动不兼容当前系统，最稳妥的方案是下载官方最新版本驱动，或者移除这个服务。

4. 如果确认是自己开发的测试驱动，再考虑开发环境下的测试签名，生产环境不建议关闭签名强制。

这个案例想提醒的是：很多人看到“服务启动失败”就急着重装系统，其实先看一眼错误码，然后用sc qc把服务指向的文件路径找出来，八成能定位。错误码就是系统给你的第一条线索，别浪费它。

4.5 WAS/W3SVC依赖：IIS起不来的连锁反应

热搜词“计算机配置→管理模板→Windows组件→远程桌面服务→远程桌面会话主机”是另一条线索：一旦服务依赖被切断，远程桌面和Web服务都会出问题。

WAS（Windows Process Activation Service）和W3SVC（World Wide Web Publishing Service）是企业Windows Server上IIS网站的命脉。WAS负责管理工作进程和协议绑定，W3SVC负责HTTP请求的接收和转发。如果其中一个被禁用，IIS站点会直接停摆。

这个问题的根源，很多时候不是手动禁用，而是优化脚本踩雷。我见过有人为了“最小化服务”，把W3SVC设成了禁用，结果第二天业务站全挂。优化服务前一定要先看依赖关系，这是我在第2章反复强调的。

远程桌面也一样。TermService（Remote Desktop Services）负责监听3389端口和会话管理，一旦被禁用，远程桌面直接连不上。后面第5章会专门讲远程桌面服务链路的应用场景。

5. 从“认识服务”到“改服务”：游戏优化脚本与部署选型中的应用

5.1 游戏优化bat：安全停服、电源与网络的一键脚本

热搜词里有一条直接的诉求：“生成一段bat批处理代码，优化Windows系统游戏性能，包括关闭不必要的后台服务、调整电源模式为高性能、优化网络延迟、清理系统临时文件。”

我提供一个相对安全的方案，但每段都会说明原理和边界，比直接甩给你脚本有用得多。脚本需要以管理员身份运行：

bat复制@echo off
chcp 65001 >nul
echo 游戏性能优化脚本（按需使用，建议先备份服务状态）

echo [1/4] 切换到高性能电源计划
powercfg -setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

echo [2/4] 关闭可选的非必要服务
sc config DiagTrack start= disabled
sc stop DiagTrack
sc config dmwappushservice start= disabled
sc stop dmwappushservice

echo [3/4] 网络参数优化
netsh int tcp set global autotuninglevel=normal
netsh int tcp set global chimney=disabled
netsh int tcp set global rss=enabled
ipconfig /flushdns

echo [4/4] 清理临时文件
del /q /f /s %TEMP%\* >nul 2>nul
del /q /f /s C:\Windows\Temp\* >nul 2>nul
echo 完成。如需恢复服务，请参考注释。
pause

逐段解释一下。

powercfg切换的高性能计划GUID是固定的8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c，在大多数Windows版本上通用。如果你已经在用卓越性能或自定义电源计划，这一步可以根据自己的GUID替换。

DiagTrack（Connected User Experiences and Telemetry）和dmwappushservice经常被建议关闭，因为它们主要做遥测和消息推送，对游戏体验没有直接帮助。但请注意，企业策略可能要求保留遥测，在自己电脑上操作即可。

网络优化里的autotuninglevel=normal是恢复默认的自适应接收窗口；chimney（TCP卸载）很多系统本来就不支持，设置了也不报错；rss（Receive Side Scaling）开启后多核CPU能更好分担网络中断处理。注意，这组命令并不能把100M宽带变成500M，它只是把网络栈参数调到一个更合理的状态。

清理临时文件时，C:\Windows\Temp里可能有关键文件被占用，删不掉也无所谓，所以加了>nul 2>nul，有报错就忽略。

必须强调的是，绝不要禁用这些服务：RPC、DcomLaunch、Windows Update（除非你清楚后果）、Print Spooler、SysMain、Windows Search、WinHTTP、DHCP Client、DNS Client。关错一个轻则功能缺失，重则系统不稳定。脚本只动了两个遥测相关服务，已经算是很克制的了。真正的游戏优化，更多是靠更新显卡驱动、关闭后台录屏、调节电源计划和NVIDIA/AMD控制面板设置，而不是把系统服务扒光。

5.2 部署MySQL：原生服务、WSL2还是Docker

热搜词里问“在Windows上部署MySQL服务，是直接安装还是用WSL2，还是Docker更合适”。这个问题正好能检验你对服务的理解程度。

从服务角度看，三种方案的差异明显：

• 原生安装：MySQL会注册一个Windows服务（服务名通常是MySQL80或MySQL），开机自启、用services.msc直接管，最贴近Windows运维习惯。生产环境或Windows-only团队建议选它。
• WSL2：MySQL跑在Linux发行版里，不是Windows服务，而是WSL内的systemd/service管理。性能接近原生，环境隔离好，适合本地开发和测试。缺点是开机自启要自行配置（比如在WSL里启用systemd并注册服务），文件系统和网络映射偶尔有坑。
• Docker Desktop：MySQL跑在容器里，依赖Docker Desktop后台服务（com.docker.service）。启动其他容器、环境一键部署非常爽，但资源占用比前两者高。在Windows上Docker Desktop本身就要占用不少内存，如果你的机器内存低于16GB，我通常不建议常驻容器跑MySQL。

直接给个对比表格：

如果你还在学习阶段，建议在WSL2里装，既不影响主系统，又能练Linux服务管理；如果团队已经全Windows运维，那就原生安装；想快速体验不同MySQL版本，Docker最方便。这个选择没有绝对标准，完全看你更熟悉哪种服务管理方式。

5.3 远程桌面会话主机：一个服务牵连“整条链路”

热搜词“计算机配置→管理模板→Windows组件→远程桌面服务→远程桌面会话主机”来自远程桌面管理配置。这个模块背后有几个关键服务：

• TermService（Remote Desktop Services）：远程桌面核心服务，负责监听3389端口和会话管理。它被禁用，远程桌面直接连不上。
• UmRdpService（Remote Desktop Services UserMode Port Redirector）：负责USB等设备重定向。
• SessionEnv（Remote Desktop Configuration）：会话环境配置。

很多时候，远程桌面连不上不一定是网络问题，而是服务被优化工具禁了。遇到远程桌面故障，先用sc query TermService看看状态，再用：

code复制netstat -ano | findstr :3389

判断端口是否在监听。如果服务没起，优先在services.msc里启动，而不是急着改防火墙。这个排查顺序能帮你省下大量时间。

我在实际处理中见过不少人把TermService设成手动，想着“要用远程桌面再手动启动”。问题在于，远程桌面是用来远程连进来的，你人都不在这台机器前，服务没起来谁帮你启动？这种“服务优化”属于典型的省错地方。远程桌面相关服务保持自动，是对自己最基本的尊重。

最后再分享两个我长期养成的习惯。第一，改动任何服务之前，先把当前所有服务的状态和启动类型导出一份，用PowerShell一条命令就行：

code复制Get-Service | Select-Object Name, Status, StartType | Export-Csv C:\services_backup.csv

这样改挂了随时能对照恢复。第二，服务不是关得越多越好，真正影响游戏和日常流畅度的瓶颈，往往是显卡驱动、磁盘占用和散热，而不是那几十MB的服务内存。理解服务、管理服务，也要学会克制地使用服务——这大概是Windows服务这门课里，最难也最重要的一课。