上位机开发入门：从通信协议到行业应用全解析-北京尧图网络

1. 先把这句话说清楚上位机开发不是“高级电脑”如果你打开招聘软件搜索“上位机”会看到一堆很有意思的描述有的要求懂 Modbus、串口、PLC有的要求会 CAN、UDS、TBox还有的写着“海康视觉雷赛运动控制”。岗位名称都叫上位机开发但工作内容、行业背景、薪资上限能差出一大截。我经常遇到两类人一类是刚毕业的学生看了一堆 C# 教程以为上位机就是写个窗口、画几个按钮另一类是从 Java、Web 方向想转过来的朋友问我上位机是不是只换个界面框架就行。这两种理解都不完全对。先给一个尽量准确的定义上位机英文叫 Host Computer通常指 PC 或工控机上运行的监控、控制软件。它的工作不是“显示数据”那么简单而是通过串口、网口、CAN 等通道与下位机通信。下位机就是另一头的 PLC、单片机、运动控制卡、嵌入式板卡、BMS 主控等设备。上位机负责下发指令、接收状态、存储数据、处理异常、展示曲线和报表。1.1 收集需求之前先搞清“上下位机”的通信逻辑有人问我“上位机和下位机是怎么配合的”其实就是一个很朴素的循环上位机发命令下位机执行完回状态或者下位机主动上报数据上位机解析、显示、落库。如果你把下位机理解成一个“四肢发达的哑巴”那上位机就是它的“大脑和嘴”大脑负责决策嘴负责说和设备听。不过这个“大脑”并没有很多人想象得那么高深。上位机工程师更像一个翻译官要把用户的业务动作翻译成下位机能理解的命令帧再把下位机发回来的二进制数据翻译成人能看懂的数值、仪表、曲线。举个例子GRBL 控制卡是很多桌面级 CNC 雕刻机、激光雕刻机在用的开源运动控制固件。你要做 GRBL 上位机本质上就是通过串口发 G-code 指令例如G0 X10 Y20同时轮询它的实时状态把位置坐标显示出来。很多人刚开始觉得难难的不是 C# 语法而是“一帧数据到底怎么组、怎么拆”。1.2 这个岗位和相邻岗位的边界为了判断一个上位机岗位到底属于什么行业最有效的方法是先看它天天在和谁打交道。下面这张表我用了很多年帮人快速区分岗位属性岗位主要工作对象关键词行业归属判断上位机开发PC/工控机软件界面、协议、通信、数据展示C#、WPF、串口、Modbus、CAN、界面看连接的硬件下位机/嵌入式开发单片机、ARM、RTOS内部逻辑C、C、中断、寄存器、外设偏硬件/固件视觉开发相机、图像处理、定位检测Halcon、OpenCV、VisionMaster、标定偏算法/光学运动控制伺服、步进、运动控制卡、机械手雷赛、固高、回原点、插补、轨迹偏自动化控制MES/WMS开发数据库、业务流程、工厂信息系统Web、数据库、API、报表偏工厂信息化很多刚接触上位机的人会分不清自己和“下位机”的职责。其实边界非常简单凡是跑在 PC 上的、用户能点界面操作的大多是上位机的活凡是烧录进芯片、靠裸机或 RTOS 跑的就是下位机的活。真正复杂的项目里上位机工程师经常还要兼职做一点视觉、运动控制、数据库的活所以这个岗位的天花板和宽度往往取决于你会不会主动往两头延伸。2. 判断行业归属先看这些行业的上位机都在干什么同一个岗位名在不同行业里完全是两回事。判断一个上位机岗位属于哪个行业不能只看公司名称要看它的产品形态、通信对象和项目重心。2.1 常见行业版图与岗位侧重行业典型项目/产品上位机连接的对象工作侧重点工业自动化产线设备、机械手、数控机床PLC、运动控制卡、伺服驱动器运动控制、工序逻辑、报警管理半导体设备晶圆分选机、贴片机、封装设备SECS/GEM 通信、EFEM、机械臂标准协议、可靠性、防呆锂电/BMS电池模组测试、储能柜监控BMS 主控、采集板、充电桩电芯电压/温度/ SOC 数据曲线、报表汽车电子OTA 升级、TBox 测试、UDS 诊断车载 ECU、TBox、CAN 总线诊断协议、升级状态机、刷写流程智能硬件/仪器无线温度监测、功率计、频谱仪低功耗模组、采集终端数据采集、低功耗网络、曲线分析通信基础设施基站/铁塔动环监控电源模块、门禁、温湿度传感器远程监控、报警派单、集中管理拿“BMS 通用上位机 v1.59”这类工具来说它常见于锂电行业。电芯多的电池包动辄几十甚至上百串电压和温度点上位机要能同时显示这么多通道的数据、实时更新曲线还要能下发均衡、继电器控制等指令。这种项目的难点不是 UI 漂亮而是数据吞吐量大、异常判断要及时、数据必须能追溯。这时候如果只会写按钮弹窗是扛不住的。再比如“铁塔上位机软件”看着好像是通信行业实际上干的事是动环监控基站里的电源状态、蓄电池电压、室内温度湿度、门禁开关状态都要汇总到上位机里。这类项目的重点往往是长时间无人值守所以断线重连、数据补传、报警记录比界面好不好看重要得多。汽车行业的上位机更特殊。像“OTA 模拟 TBox 上位机”干的事是在实验室里模拟一个真实 TBox 的行为向云端上报升级包下载状态、校验结果、设备版本号再把云端下发的升级指令回传给测试人员。它典型的特点是项目代码量不大但状态机必须非常严谨因为一个状态跑错就可能把整条 OTA 链路测试结果带偏。2.2 识别招聘信息的四个判断维度我建议所有想投上位机岗位的人把招聘信息里这四件事找出来基本就能判断岗位的行业底色连接对象是什么。写 PLC、板卡、电池、车载 ECU行业差异就出来了。连接对象决定了你要不要去车间、实验室还是机房。用什么协议。Modbus、串口协议大概率是工业自动化CAN、UDS、以太网诊断大概率是汽车电子SECS/GEM 大概率是半导体。界面功能侧重什么。大量曲线和报表偏数据采集大量参数配置和点位运动偏运动控制大量状态机与升级流程偏车载或通信。现场环境描述。写“需要配合产线调试”“可接受短期出差”的多半是工业自动化或者设备厂写“实验室环境”“办公为主”的偏产品研发。当你把这些判断清楚了再看“上位机开发”这四个字就不会只盯着薪资对比而是知道同样是 2 万月薪一个可能是 3C 自动化设备里天天和雷赛运动控制卡打交道的岗位另一个可能是半导体设备里要啃 SECS 协议的岗位两者积累的行业知识完全不是一回事。3. 上位机技能矩阵那些热词背后的真问题这一节把行业里反复出现的技能点拆开说。很多人搜“上位机开发教程”搜出来一屏幕都是“创建一个窗口再放个按钮”然后就没有然后了。真正的上位机技能树比这要长得多。3.1 C# 上位机与 VS 版本兼容陷阱当前最主流的上位机语言还是 C#框架无非 WinForms 和 WPF。但要提醒一句版本兼容问题是这个领域里非常普遍的坑尤其是老项目。有人问“VS2019 开发的 C# 上位机源码程序能用 VS2015 打开吗”答案是“不一定而且大概率要处理一下”。这里面有几个关键点项目文件格式。VS2019 可以创建传统格式的.csproj也可以创建新版 SDK-Style 格式Project SdkMicrosoft.NET.Sdk。如果建的是 SDK-Style 工程VS2015 根本认不出来不是代码兼容问题是工程文件格式不兼容。目标框架。如果项目目标框架是 .NET Core 或 .NET 5/6VS2015 也不支持因为它只能比较完整地支持 .NET Framework。很多 C# 上位机项目稳妥起见仍然用 .NET Framework 4.5.2 或 4.7.2原因之一就是为了部署到老工控机上不用装额外运行时。语言版本特性。就算目标框架是 .NET FrameworkVS2019 默认可能允许用 C# 7/8 甚至更高语法比如out var、元组、模式匹配、可空引用类型。VS2015 默认支持到 C# 6遇到这些语法就会编译报错。解决办法是在.csproj里显式指定LangVersion7.0/LangVersion或写低版本兼容代码。NuGet 依赖。VS2015 的 NuGet 版本较旧有些包版本无法解析所以打开项目后第一件事是看“管理 NuGet 程序包”有没有红色感叹号。如果你维护的是老产线项目我的建议是能用旧格式解决就别为了赶时髦创建 SDK-Style 工程。上位机软件追求的往往是“能跑十年”不是“语法最新”。3.2 通信协议串口、Modbus、CAN、TCP上位机开发的核心不是控件是通信。这里把最常见的四类协议归纳一下。串口很多人学校时期学过但工程里真正要注意的是不定长数据的组包。下位机可能一次性发来 50 个字节也可能分 5 次发完上位机不能每收到一段就处理。通用做法是用缓冲区拼接再按帧头、帧尾、长度域来提取完整报文。如果协议里还有 CRC 校验那就更标准了。问“Vofa 上位机怎么给单片机发送数据”其实 Vofa 本身提供几种协议格式文本模式下直接按分隔符发字符串二进制模式下按帧头帧尾加校验发十六进制帧。无论哪种你作为上位机开发者都要自己实现发送与解析。Modbus工业现场最常见的命令协议。Modbus RTU 通过串口传报文格式是地址码功能码数据 CRC16Modbus TCP 通过网口传报文格式是 MBAP 报文头功能码数据。做“Modbus 上位机控制软件”时核心就是实现 03 读保持寄存器、06 写单个寄存器、16 写多个寄存器这几条指令再做一个通用的寄存器读写面板。很多国产 PLC、触摸屏、板卡都兼容 Modbus所以这套协议学会了基本可以横着走小半个工业自动化行业。CAN汽车电子和 BMS 里躲不开。CAN 报文不长标准帧只有 ID、DLC、8 字节数据。上位机要做的是把 CAN FD/2.0 的原始报文解析成物理量比如某个 ID 的 Data[1] 和 Data[2] 拼起来乘以精度 0.1就是当前电压。调试工具里Cangaroo 是 Linux 上常见的免费 CAN 工具Windows 上很多人会配 PCAN、CANpro 或厂商自带的上位机。关键是你要懂 DBC 文件或者手动查协议表。TCP/UDP半导体设备、视觉相机、远程设备经常用。TCP 要注意粘包、半包、心跳和断线重连UDP 要注意丢包、乱序、广播地址。很多“上位机搜索不到设备”的问题其实都是 UDP 广播地址填错或者 Windows 防火墙把端口拦截了。工控机上尤其常见因为现场网络环境五花八门比如拓邦上位机搜索不到设备十有八九是网卡 IP 段不对、子网掩码不一致或程序被防火墙挡住。3.3 硬件设备联动运动控制卡、视觉、PLC、触摸屏很多上位机岗位不是只写软件而是要和各种硬件联动。以“海康视觉和雷赛运动控制的 WPF 上位机程序”为例。这类项目的本质是相机拍完照视觉软件算出目标坐标上位机再把坐标发给雷赛运动控制卡控制伺服电机移动到位。技术上你至少要处理好几件事海康 SDK 的相机采集回调、图像处理结果的坐标换算、雷赛控制卡的 DLL 调用打开卡、回原点、点位运动、读取 IO、UI 的实时刷新。这一段跑下来你会明显感觉到多线程和资源释放的重要性。我曾经遇到一个项目程序只要连续运行两小时界面就卡死最后查出来是相机采集回调里直接做了 UI 操作导致跨线程访问控件异常堆积。这类问题不深入现场很难发现。还有一类是“威纶通触摸屏与上位机板卡通过网线连接进行 Modbus TCP 通讯”的工程配置。很多人一开始会困惑触摸屏是 HMI上位机是另外一台 PC到底谁是主站其实在 Modbus TCP 里发起读写的客户端是主站。威纶通在 EBpro 软件里新建工程时要选“设备类型”为对应板卡支持的 Modbus TCP Slave上位机板卡作为服务器端需要配置好 IP、端口端口默认一般是 502。做这类项目时最容易出错的是“站号”对不上Modbus TCP 的单元 ID 在很多设备里默认是 255但板卡可能要求填 1两边不一致时通信就是不通。这种问题靠看代码是看不出来的必须抓报文才能定位。如果团队用的是 C 或需要跨平台那就会遇到“QT 上位机”。QT 做上位机控制 PLC 也很普遍尤其是老牌工控企业和一些 Linux 嵌入式设备。QT 的优势是跨平台和 QModbus 库相对现代一点的项目会配合 QML 做界面。但坦白说国内大量产线用的还是 Windows C#因为部署和维护成本相对低。3.4 调试工具Vofa、Cangaroo、串口助手、共享盘上位机开发效率高低很大程度取决于你会不会用调试工具。我自己的工具箱常年放着这几样Vofa适合看波形和调试 PID。下位机通过串口把数据按 Vofa 支持的格式发上来上位机直接显示成动态曲线。以前调电机 PID 时没有曲线工具就只能盯着数值文本猜有了 Vofa 一眼就能看出超调、振荡、响应速度。它还能给单片机发自定义数据算是个“能发送命令的上位机”入门工具。Serial Port Assistant / COM 工具日常收发十六进制数据、模拟下位机回包。很多上位机 bug其实可以先不用接真设备用串口工具手动回一包数据就能复现。Cangaroo / PCAN-View / CANpro看 CAN 报文、发诊断报文、回放总线数据。BMS、TBox、VCU 联调时没有这类工具等于盲人摸象。抓包工具排查 Modbus TCP、TCP/UDP 通信问题时用 Wireshark 抓包能看到谁在发起连接、谁拒绝连接、数据到底卡在哪一层。“上位机电脑重新设置共享盘”这个需求也比较常见。产线维护时很多上位机程序都放在共享盘上方便多台工控机同步更新。设置共享盘的核心是权限要给运行账户写权限但又不建议给 Everyone 完全控制因为杀毒软件、误删文件的风险都会上升。真正稳妥的做法是发布程序放在共享盘只读区工控机本地放运行缓存版本更新用脚本同步。这样既不耽误部署又能避免多台机器同时读写导致程序文件冲突。4. 从需求到联调一条完整上位机项目的真实工作流很多人以为上位机开发就是“写界面读数据”但真实流程远比这长。一个稍微正经点的上位机项目通常会走完下面这段路。4.1 需求阶段最容易漏掉的事需求评审时产品经理可能会扔给你一张设备清单和几页协议表然后说“做一个上位机控制软件”。如果你只关心“界面怎么做”一定会漏掉下面这些数据点表是否完整。每个寄存器/信号的含义、单位、精度、读写权限都要列清楚。有一次项目里下位机工程师口头说某个寄存器是 0.1 精度结果现场发现实际是 0.01整个界面显示全部乘了十倍排查了一整天才发现。异常场景怎么展示。通信超时时界面变灰还是弹窗数据连续几帧校验失败要不要报警下位机掉线后历史数据怎么补传这些需求不提开发时就只能猜。部署环境是什么。工控机系统是 Win7 还是 Win10有没有装 .NET Framework屏幕分辨率是 1024×768 还是 4K曾经有项目界面在开发电脑上好看到产线工控机上按钮全被挤出屏幕就是因为没考虑 125% 缩放。4.2 技术选型WinForms、WPF 还是 QT每次新项目都会有人纠结框架。我的经验是WinForms适合快速交付、逻辑简单、维护压力小的项目。它拖控件方便数据绑定直接老工程师维护成本低。缺点是界面不够现代高分辨率适配和复杂动画很痛苦。WPF适合对界面交互有要求、需要 MVVM 架构、动态数据绑定多的项目。WPF 做上位机界面确实漂亮实时曲线、工位状态、多页面导航都很顺手。代价是学习曲线更陡团队里如果有人只会 WinForms会把他逼疯。QT适合已经有 C 技术栈、或者需要跨平台的项目。QT 控制 PLC、做工业平板界面都是成熟方案。LabVIEW如果项目是仪器仪表控制和采集LabVIEW 确实能快速搭出控制界面。但退役工程师多、现代 UI 薄弱、数据结构化差新项目我一般不推荐。另外“上位机页面组态编辑器”这个方向也很值得关注。很多标准化设备商会做一个通用上位机平台把控件、图表、通信协议都做成可配置项交付到现场后不用写代码通过拖拽组态出每台设备的监控页面。这个思路可以减少重复开发但前期投入很大不太适合单项目定制开发的小团队。4.3 编码与调测粘包、半包、跨线程进入开发阶段后问题就集中在几个老生常谈又绕不开的地方。粘包半包TCP 和串口数据都可能出现。收数据时不能直接按“收到一次消息”处理正确姿势是维护一个接收缓冲区按照帧协议从缓冲区里一帧一帧地截取。协议设计时最好加上“起始符数据长度校验”这样的结构半包就等后续数据补全粘包就按长度切分。跨线程访问 UI串口数据接收、TCP 回调、相机回调都是在非 UI 线程直接操作控件会报异常或偶发闪退。WinForms 里用Invoke或BeginInvokeWPF 里用Dispatcher或数据绑定。更深一层我建议这类数据流设计中引入队列或 Channel接收线程把原始报文丢进队列UI 线程按固定周期取数据刷新而不是每来一包数据就抢着刷界面。这样既能减少卡顿又方便后续扩展多设备接入。UI 卡顿实时曲线刷新、大批量点表显示是卡顿重灾区。自己画的曲线控件如果直接在 UI 线程循环绘制数据量大时必卡。常用优化思路是曲线用增量绘制模式或者限制刷新频率比如每秒 10 帧表格用 UI 虚拟化大数据量查询走异步。性能问题不是到现场才解决的开发阶段就要用模拟数据压测。4.4 现场实施与部署共享盘、搜索不到设备这类问题上位机项目的最后一公里永远在现场。再小的项目只要到了现场就会见识到什么叫“开发环境没问题生产环境到处是问题”。先说“上位机电脑重新设置共享盘”。很多产线的工控机没有独立显示器或键盘维护人员是从办公室远程连过去或者通过共享盘直接把升级包推过去。设置共享盘时要注意共享文件夹的访问权限要精确到具体用户或用户组。工控机如果启用了防火墙要允许“文件和打印机共享”规则。杀毒软件容易拦截共享访问尤其是一些国产安全软件经常导致“明明开了共享却访问不了”。再说“拓邦上位机搜索不到设备”。我之前遇到过类似的设备搜索问题检查步骤基本是第一看电脑 IP 和设备 IP 是否在同一网段第二看子网掩码对不对第三用ping验证物理连通第四关闭防火墙或添加例外端口第五确认上位机选择的是 UDP 广播还是 TCP 直连广播地址有没有设对。大多数“搜索不到”的问题根本不是程序 bug而是网络环境配置问题。现场联调还有一个容易被忽略的点日志。一定要让上位机把收到的原始报文、解析后的关键数据、通信断线恢复时间点都写进日志文件。很多现场问题不是你盯着就能复现的一旦出了异常靠日志回放才能定位。没有日志的上位机项目等于裸奔。5. 面试、转行和职业发展留给正在看这个岗位的人聊完技术说说岗位本身。搜索“上位机面试题”的人非常多这说明不少人正在入行和跳槽的关口。这一节我尽量讲点别人没细讲的东西。5.1 上位机面试到底问什么上位机岗位的面试题和纯 Web 后端面试完全是两套逻辑。常见方向包括语言基础方向委托和事件的区别事件为什么不能在外面直接赋值。async/await的线程切换原理UI 线程里用异步会不会卡界面。string是不可变的大量拼接为什么用StringBuilder。值类型和引用类型装箱拆箱。通信方向串口数据接收不定长时你怎么组包Modbus RTU 和 Modbus TCP 有什么区别CAN 报文里长度为 8 字节的数据如何转成 floatTCP 粘包半包你怎么处理如果设备每隔 100ms 发一包数据界面要实时显示你会怎么做项目/场景题上位机突然连不上设备你从哪些方面排查下位机频繁重启但现场没人能复现你怎么定位有一个旧项目是 VS2019 写的客户机器只有 VS2015你怎么办我面试的时候比起背八股更爱看一个人怎么拆解问题。比如“设备隔几分钟掉线一次”有人会说“改用 TCP 长连接”有人会问“掉线时上位机在做什么设备状态灯什么样是只有一台设备掉还是所有设备掉”。后者才是能干活的人。5.2 Java 转上位机难吗很多从 Java Web 转过来的朋友问过这个问题。我的结论是不难但你要补的东西不是语法而是“硬件感”。Java 的优势在于 OOP、多线程、常用设计模式这些底子这些在上位机里一样用得上。你需要补的是进制与字节操作。byte、short、int的大小端转换按位与或、移位、位标志解析这些在解析 CAN 报文和 Modbus 寄存器时天天用。Java 里处理字节数组是很常见的但你可能没意识到设备报文里还有“无符号数”这种概念C# 里的ushort、uint就很顺手。非托管资源管理。串口、网络连接、设备句柄用完必须释放。IDisposable、using语句、finally处理是上位机的命门。现场调试意识。上位机不是接口联调完就结束了你要能扛着笔记本去车间蹲在机柜旁看数据对不对。这是很多转行的人最不适应的。给一个相对平滑的学习路线先拿 WinForms 做一个串口助手实现帧格式组包解析再写一个 Modbus 读写工具能连接真实 PLC 或者模拟器然后做一个完整的上位机项目控制一台小型设备或采集一路传感器最后学 WPF 和 MVVM。我见过不少人被小红书上一口气“三天学完 WPF”的节奏带偏其实没必要脚踏实地做两个小工具比背十节网课有用。市面上也有很多“C# 上位机开发教程”但适合自己的方式确实是“边做边查”。5.3 职业发展的两个方向上位机工程师干到三五年后一般会分两条路。一条是技术方向往上走变成上位机架构师、工业软件平台负责人精通多协议、多线程、设备联动、数据库优化能设计一套适用多条产线的通用上位机平台。这条路需要你持续补计算机基础、软件架构和自动化控制知识。另一条是行业方向把某个行业的业务吃透。比如电池行业你做三年 BMS 上位机就会积累很多电芯特性、均衡策略、析锂判断等业务知识汽车行业做三年 OTA/TBox你会对升级状态机、诊断规范、刷写流程了如指掌。到了这个阶段你的价值已经不只是一个“写软件的”而是“懂电池业务的上位机工程师”或“懂车载升级的测试开发”。我的建议是两条路不要死二选一。技术是敲门砖行业是放大器。初期多花时间把通信协议、线程模型、现场问题排查能力打扎实中期选择一个有壁垒的行业深耕。半导体设备的上位机为什么薪资普遍高不是因为 C# 写得更花哨而是因为 SECS/GEM 协议、设备自动化流程、晶圆生产环境这些行业知识外面的人短期补不上来。带团队这几年我最担心的不是手下人写不出界面而是他只满足于“界面上有数据显示就行”。上位机这个岗位本质上做的是“硬件世界和软件世界的连接器”。连接器看着不起眼但一旦断掉整条产线都停摆。能意识到这一点的工程师才不会把自己做窄。拿我自己来说每到一个现场我都会跟车间老师傅聊几句设备工艺听他们抱怨哪里不好用。这些东西不会立刻写进代码但会在下一次方案设计时变成别人想不到的细节。做上位机最终拼的真的不只是代码。

上位机开发入门：从通信协议到行业应用全解析

相关推荐

es-toolkit 兼容层 defaultTo 详解：统一处理 null / undefined / NaN 的默认值守卫

如何用MathModelAgent做多模型混搭？给每个Agent配不同模型以降低成本的技术

Magic Resume：免费开源的 AI 简历编辑器，30 分钟导出可投递的 PDF

更多资讯

mlx-audio 中的 Dramabox 语音合成：基于 LTX DiT + Gemma 编码器的 48 kHz 立体声 TTS 与参考音频克隆实现

ag-kit API Patterns 技能库：基于 OpenAPI 的 API 文档编写原则与自动化校验实践

Rails Active Record Callbacks 实战指南：在对象生命周期中挂接业务逻辑

西门子TIA博途SCL模拟量处理库：滤波+报警一体化解决方案

Loco 中文指南：用 Rust 快速构建类 Rails 的 Web 应用

使用 lifx.paint_theme 为 LIFX 灯具绘制预设主题与自定义调色板

今日更新

基于MATLAB的CRI显色指数计算：从SPD光谱到Ra的完整流程

JSP+Servlet+MySQL博客系统源码部署与优化全攻略

蜂窝调度算法 MATLAB 实现：比例公平、轮询与最大 C/I 对比

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？