项目名stream-408073756662300811_overlay乍看像一串随机编号但如果你经历过视频流处理、直播转码、摄像头接入这类开发任务一眼就能猜出它的结构一个stream流任务一串任务 ID一个overlay叠加层标记。类似的任务名在真实系统里非常常见比如把一路视频流拉进来叠加上时间戳、水印、站点名称再推送出去。问题在于stream和overlay这两个词在技术世界里撞名频率极高。媒体流里有 StreamJava 里有 StreamRedis 里也有 Stream而overlay在容器里是网络层在 UI 里是弹层在流媒体里又变成了画面叠加。很多开发者在排查问题时其实是被同名概念绕晕了任务明明报的是stream disconnected before completion但查了半天 Java Stream 代码方向完全错了。本文围绕stream-408073756662300811_overlay这个典型任务名展开讲清楚三件事Stream 在不同技术语境下到底是什么Overlay 叠加在流媒体实战中怎么落地以及stream disconnected before completion这类报错到底该怎么查。读完你会得到一套可以直接复用的排查思路和可运行的命令示例而不是一堆零散概念。1. 从任务名反推业务stream、任务ID、overlay 分别代表什么先把这个任务名拆开看。stream-408073756662300811_overlay的核心结构是三个部分片段含义常见对应物stream这是一条流式任务视频流、数据流、日志流408073756662300811任务 ID通常是时间、节点、请求的全局唯一标识雪花 ID、时间戳、UUID 简写overlay这个任务要执行叠加操作视频水印、OSD 文字、字幕、画中画在流媒体系统中这种命名经常出现在任务调度平台里。比如一个转码服务收到用户上传的视频就会生成一个类似stream-{id}_overlay的任务表示“我要把某个画面内容叠加到主视频上然后输出”。如果你负责维护这类系统遇到这个任务名第一反应应该是主视频源在哪、叠加素材是什么、叠加坐标在哪、输出目标是什么。一个常见误区是看到overlay就只想着画面叠加忽略了stream部分。实际上在流媒体任务里stream是主线overlay只是主线上挂的一个滤镜节点。主线断了overlay 做得再漂亮也白搭。这就像快递运输stream是运输链路overlay是包装盒上的贴纸。链路断了贴纸再好也没用。在实际项目里stream-408073756662300811_overlay还可能出现在视频监控、直播推流、云录制、赛事转播等场景。它不一定来自 FFmpeg 命令行也可能是某个视频处理 SDK 里的内部任务名。但无论底层是什么任务命名传达的信息是一致的这是一条需要叠加处理的流式任务。所以拿到这类任务名后先别急着找代码而是先问三个问题这条 stream 的数据源是什么文件、摄像头、RTMP 推流还是 HTTP 拉流overlay 叠加的内容是动态的还是静态的是图像、文字还是另一路视频任务完成后往哪走保存到本地、生成 HLS 分片还是推回直播服务器把这三个问题确认完再进入处理环节思路会清晰很多。2. Stream 的三个技术世界媒体流、Java Stream 与 Redis StreamStream是计算机领域被复用得最狠的单词之一。很多人看到stream报错就开始往自己擅长的方向猜结果经常对不上号。这里把最常见的三种 Stream 拆开对比一下。类型本质典型形态典型应用媒体流 / 网络流时间序列上的连续数据RTMP、HLS、m3u8、WebSocket、TCP 长连接直播、推拉流、视频文件传输Java Stream集合数据的函数式处理管道list.stream().map().filter()列表过滤、分组、去重、转 MapRedis Stream内存数据库中的消息队列结构XADD、XREAD、XREADGROUP消息队列、事件广播、日志收集这三者虽然都叫 Stream但机制完全不同。媒体流的核心特征是“有方向、有生命周期、有传输层状态”。它关心的是数据能不能持续到达、连接会不会断、断了怎么重连。你在日志里看到stream disconnected before completion绝大多数情况下指的是这种流。Java Stream 的核心特征是“一次性的惰性计算管道”。它的数据来自一个集合或生成函数处理完就结束没有连接、没有网络、没有断线重连的概念。它更像是一条流水线上的工位一个对象经过filter工位、map工位最后被collect打包。这里没有长连接所以不存在“断开”的问题。Redis Stream 的核心特征是“持久化的消息序列”。它把消息写到 Redis 内存里消费者通过游标读取。它关心的不是网络传输那是 Redis 连接池的事而是消息的顺序、消费组、ACK 确认、消息积压。这三个世界平时各干各的但在一个大型系统里可能同时存在。一个典型例子Java 服务从 Redis Stream 里读取一批任务 ID用一个 Java Stream 管道去重和过滤然后拼出视频地址通过 HTTP 拉流和 FFmpeg 做 overlay 处理。如果整个过程是一条链路三个 Stream 在三个环节各司其职。这里有个很常见的排查陷阱。比如your inputstream was neither an OLE2 stream, nor an OOXML stream这类报错出现在 Java 里但其实是文件流解析问题——程序把文件读成了字节流结果发现它既不是旧版 Excel 格式也不是新版 Office 格式。很多新手看到inputstream就理解成“网络流”实际上这是 Java IO 里的文件字节流。排查方向应该是文件类型、文件完整性、解析库选择而不是网络问题。所以遇到 stream 相关问题时先明确自己此刻面对的是哪一种 Stream。这一步判断错了后面的排查大概率是浪费时间。3. 流媒体 Overlay 叠加原理、坐标与典型场景Overlay 在流媒体里的意思是把一路画面叠加到另一路画面之上。和用户界面里的“浮层”很像但这里讲的是视频像素层面的叠加对应 FFmpeg 滤镜系统里的overlay滤镜。它的核心语法模型是一个主输入[0:v]一个叠加输入[1:v]通过overlay滤镜按坐标放到主画面上得到合成后的输出。公式是overlayX坐标:Y坐标坐标原点是左上角(0,0)向右、向下为正。为了适应不同分辨率FFmpeg 还提供了一组动态变量变量含义main_w主画面宽度main_h主画面高度overlay_w叠加画面宽度overlay_h叠加画面高度比如要把 logo 放到主画面右上角并保留 20 像素边距坐标写法是main_w-overlay_w-20:20。放到右下角则是main_w-overlay_w-20:main_h-overlay_h-20。这种写法在动态分辨率转码时特别有用因为不同输入视频的分辨率可能完全不一样写死坐标会导致叠加位置不对。Overlay 画面叠加的典型场景包括摄像头画面叠加时间戳、地点、设备编号也就是热搜里常提到的“overlay 相机”。安防监控的 OSD 信息就是这么打上去的时间戳必须跟随系统时间变化所以用drawtext滤镜配合本地时间格式化。直播画面叠加频道 logo、台标、赛事比分。视频会议画面叠加参会者名牌、会议水印。画中画场景把一个小窗口视频叠加到大画面上常见于教学录屏、游戏直播、连线直播。从实现上看overlay 的难点不在于“能不能叠”而在于“叠上去之后画面效果对不对”。最容易出问题的有三个地方坐标写死导致在不同分辨率下位置偏移叠加素材尺寸不透明导致黑边滤镜链顺序错误导致输出没有效果。前两个问题在调试时一眼就能看出来第三个问题则需要理解 FFmpeg 滤镜链的组装顺序。理解了 overlay 的原理下一节进入实际命令。这是整个流媒体任务里最核心的一段也是stream-408073756662300811_overlay这类任务通常要完成的业务逻辑。4. 完整示例摄像头画面叠加时间戳并输出 HLS下面用三个可运行的示例把 overlay 任务完整走一遍。演示环境以 Linux 为主因为视频采集设备在 Linux 上最常用 V4L2 接口。macOS 和 Windows 的采集参数不同但 overlay 处理逻辑是通用的具体参数以你的环境为准。4.1 基础环境准备运行下面命令前先确认 FFmpeg 已安装并且编译时带了libx264和 HLS 分片输出能力ffmpeg -version如果输出里能看到--enable-libx264说明编码器可用。没有的话在 Ubuntu/Debian 上可以这样安装sudo apt update sudo apt install ffmpegWindows 建议从官方渠道下载稳定版 FFmpeg 并加入 PATHmacOS 可以使用 Homebrew 安装。这里不具体固定版本重点是通用思路。4.2 命令一本地视频叠加图片水印先处理最简单的情况一段本地视频叠加一张本地图片输出带水印的新视频。ffmpeg -re -i input.mp4 -i logo.png \ -filter_complex [0:v][1:v]overlaymain_w-overlay_w-20:20 \ -c:v libx264 -c:a copy output.mp4命令说明-re表示按原始帧率读取输入适合后续模拟直播推流。本地文件处理时也可以不加。-i input.mp4 -i logo.png两个输入索引分别是0和1。-filter_complex [0:v][1:v]overlaymain_w-overlay_w-20:20把主视频0:v和图片1:v合成图片位于右上角距离边缘 20 像素。-c:v libx264用 H.264 编码输出视频。-c:a copy音频直接复制不重新编码节省时间。这一步如果顺利output.mp4播放时右上角应该能看到水印。这里最容易出的坑是logo.png分辨率太大把主画面主要内容盖住所以实际项目里一般会先对叠加素材做一次缩放比如ffmpeg -i input.mp4 -i logo.png \ -filter_complex [1:v]scale200:-1[logo];[0:v][logo]overlaymain_w-overlay_w-20:20 \ -c:v libx264 -c:a copy output.mp4scale200:-1是把图片宽度缩放为 200 像素高度按比例自适应。缩放后的视频用[logo]标记再进入 overlay 合成。4.3 命令二摄像头采集画面叠加时间戳并推流这一步更接近实战。从 Linux 摄像头设备采集画面叠加当前时间文字再推送到直播服务器。ffmpeg -f v4l2 -i /dev/video0 \ -vf drawtexttext%{localtime}:x10:ymain_h-40:fontsize24:fontcolorwhite:fontfile/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf \ -c:v libx264 -preset ultrafast -tune zerolatency \ -f flv rtmp://your-server/live/stream-408073756662300811命令说明-f v4l2 -i /dev/video0读取 Linux 摄像头设备设备节点按实际环境替换。-vf是简单滤镜链drawtext用于在画面上绘制文字。%{localtime}输出本地时间。字体文件路径在 Linux 上常见但不同发行版路径可能不同如果提示找不到字体用fc-list | grep -i dejavu查看实际路径。-preset ultrafast -tune zerolatency是直播推流场景常用参数压低编码延迟尤其适合摄像头画面和实时推流。-f flv rtmp://your-server/live/stream-xxx输出到 RTMP 服务。如果你的直播平台不支持 RTMP换成平台指定的推流地址即可。这里值得特别强调的是drawtext叠加的文本值在命令里是被当作常量处理的%{localtime}是 FFmpeg 在渲染时扩展的特殊变量。如果改成textcurrent_time之类的固定写法画面上就不会出现动态时间。很多第一次用的人在这里踩坑以为文字不变化是编码问题其实是变量用法错了。如果你只是想把叠加后的画面保存成本地文件把最后的推流地址换成文件名即可ffmpeg -f v4l2 -i /dev/video0 \ -vf drawtexttext%{localtime}:x10:ymain_h-40:fontsize24:fontcolorwhite:fontfile/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf \ -c:v libx264 -preset ultrafast \ camera_osd.mp44.4 命令三输出 HLS 分片和 m3u8 播放列表HLS 是当前移动端和浏览器端最常见的直播点播协议。它把一路流切成若干个.ts分片用一个.m3u8索引文件来组织。热搜里经常出现的stream .m3u8指的就是这类文件。ffmpeg -re -i input.mp4 -c copy \ -f hls -hls_time 6 -hls_list_size 0 \ stream-408073756662300811.m3u8命令说明-c copy表示不转码直接复制原始编码数据速度快但要求输入是 H.264/AAC 等可直接封装的格式。-hls_time 6每个分片时长 6 秒。-hls_list_size 0表示不限制播放列表里的分片数量适合录制完整节目如果做直播回看通常会写成后续清理策略。输出的stream-408073756662300811.m3u8会自动管理同名的.ts分片。如果要同时做 overlay 和 HLS 输出把前面命令的组合起来ffmpeg -re -f v4l2 -i /dev/video0 -i logo.png \ -filter_complex [0:v][1:v]overlay10:10,drawtexttext%{localtime}:x10:ymain_h-40:fontsize24:fontcolorwhite \ -c:v libx264 -preset ultrafast \ -f hls -hls_time 6 -hls_list_size 0 \ live/stream-408073756662300811.m3u8注意-filter_complex和-vf不能混用。overlay10:10,drawtext...是在同一个滤镜链里用逗号一层一层往后传。这个顺序就是叠加顺序先做 logo 叠加再在合成后的画面上叠加时间戳。4.5 如何判断运行成功无论执行哪条命令成功与否看三点FFmpeg 进程没有报错退出命令行一直有输出没有出现error、failed、Invalid argument等关键字。输出文件或推流地址已经生成。本地文件可以直接看文件大小是否在持续增长推流可以从直播服务端的事件日志确认收到流。用播放器打开产物肉眼确认叠加层位置、大小、透明度是否正确。如果失败第一步先看 FFmpeg 的 stderr 输出。视频处理的报错通常已经提示了问题位置设备打开失败、滤镜语法错误、编码器缺少、字体路径不存在等。先不要急着改代码把前 30 行日志完整看一遍大部分问题都能定位。5. 编程世界的 StreamJava 流式处理与 Redis Stream 实战对照看完媒体流再看两个面试和工作里高频出现的 StreamJava Stream 和 Redis Stream。它们和媒体流同名但解决的问题完全不是一回事。5.1 Java Stream集合管道处理Java Stream 是 Java 8 引入的函数式处理模型。它在内存里对一个集合元素序列做惰性处理适合过滤、去重、分组、映射等批量操作。热搜里有一句“stream 流根据某个字段进行去重”这是实际开发里很高频的需求。假设有一个User列表需要按userId字段去重。第一种写法是自定义去重函数public class User { private Long userId; private String name; // 省略 getter/setter }public static T PredicateT distinctByKey(Function? super T, ? keyExtractor) { MapObject, Boolean seen new ConcurrentHashMap(); return t - seen.putIfAbsent(keyExtractor.apply(t), Boolean.TRUE) null; } ListUser distinctUsers users.stream() .filter(distinctByKey(User::getUserId)) .collect(Collectors.toList());第二种写法是利用TreeSet去重后再转回列表ListUser distinctUsers users.stream() .collect(Collectors.collectingAndThen( Collectors.toCollection(() - new TreeSet( Comparator.comparing(User::getUserId))), ArrayList::new));第一种适合保留原列表顺序第二种适合在排序逻辑简单时快速拿到去重结果。这是 Java Stream 的典型写法。它的特点是整个管道一次遍历完成数据不经过网络、不落盘。5.2 Redis Stream消息队列拉取Redis Stream 是 Redis 5.0 引入的消息队列数据结构。它以追加日志的方式组织消息支持消费组、ACK 确认、待处理列表和消息积压统计。和 Java Stream 有本质区别Java Stream 作用于内存里的集合Redis Stream 是跨进程的消息传递。Redis 侧先创建流并写入消息XADD sensor:data * temperature 25.5 humidity 60创建消费组XGROUP CREATE sensor:data group1 0消费者拉取消息XREADGROUP GROUP group1 consumer1 COUNT 10 STREAMS sensor:data 是特殊 ID表示“从未消费过的消息”。消费者处理完需要确认XACK sensor:data group1 1600000000000-0在 Spring Boot 项目里用StringRedisTemplate读取 Redis Stream 消息的代码大致如下。不同版本的spring-data-redisAPI 略有出入包名以项目实际依赖为准Service public class SensorStreamService { Autowired private StringRedisTemplate redisTemplate; public void pullMessages(String streamKey) { ListMapRecordString, Object, Object records redisTemplate .opsForStream() .range(streamKey, Range.unbounded()); for (MapRecordString, Object, Object record : records) { MapObject, Object value record.getValue(); // 处理业务逻辑 System.out.println(streamId record.getId() , value value); } } }opsForStream().range()只是从流中读取历史消息。生产环境中更推荐使用StreamMessageListenerContainer配合StreamListener做持续监听但监听容器的配置项和版本耦合较紧建议先跑通上面的基础读取再根据实际场景调研监听器方案。5.3 两种 Stream 的适用边界Java Stream 和 Redis Stream 都叫 Stream但完全没有必要互相替代。Java Stream 是一次性的内存管道处理对象是已经存在的数据集合Redis Stream 是持续追加的消息序列处理对象是时间和事件驱动的消息。你的业务如果是“把请求里的列表过滤去重以后入库”用 Java Stream如果是“多个服务之间解耦传递任务”用 Redis Stream。回到stream-408073756662300811_overlay的场景任务调度器完全可以先把待处理视频的 ID 写入 Redis Stream消费者从 Redis Stream 读到视频 ID用 Java Stream 做去重和过滤再调用 FFmpeg 做媒体流 overlay。这样一条链路里三个 Stream 各司其职互不干扰。分清这一点你就不会再被同名概念绕进去。6. 排查清单stream disconnected before completion 系列错误开发过程中最头疼的不是功能不会写而是任务运行到一半报stream disconnected before completion。这类错误在热搜里出现频率极高而且伴随不同的后缀transport error: network error、websocket closed by server before res、upstream request failed、tls handshake eof、io error: peer closed connection with等。表面看是不同错误本质上是同一个问题流在业务完成之前被提前终止了。至于为什么终止则要看具体是哪一层断了。6.1 常见错误归类错误片段典型场景可能原因排查方向transport error: network error数据传输中断网络抖动、中间链路超时、防火墙断开空闲连接查看网络拓扑、连续 ping、抓包确认丢包位置you have no credits remaining调用付费流式接口账户额度不足或超额检查账户配额、余额、用量统计确认是否有计费限制websocket closed by server before resWebSocket 长连接流服务端主动关闭、心跳超时被回收检查服务端日志、客户端心跳间隔、服务端 idle 超时配置upstream request failed网关转发上游上游服务 5xx、负载过高、限流查上游服务日志、确认熔断和限流策略tls handshake eofHTTPS/WSS 流TLS 握手被对端中断、证书链不完整用 curl 带详细输出测试握手、检查证书有效期和证书链stream closed before response长连接请求服务端提前关闭流查看服务端访问日志、确认是否超时触发断开io error: peer closed connection withTCP 长连接对端关闭连接、连接被系统回收用 tcpdump 或 Wireshark 抓包、查看服务端连接回收策略这里需要提醒一个排查顺序先分清是客户端主动断、服务端主动断还是网络中间断。最简单的办法是看两端日志。客户端日志里如果出现timeout、reset多半是等待响应超时服务端日志里如果出现idle timeout、client closed说明是服务端或网关的策略回收了连接。如果你有权限在网络路径上做抓包再结合抓包结果定位。6.2 通用排查流程遇到stream disconnected before completion按下面顺序走多数问题能收敛记录错误前后的完整上下文包括请求 ID、任务 ID、耗时。stream-408073756662300811_overlay这种任务 ID 就是为了追踪日志用的。看服务端日志区分是服务端主动关闭还是客户端断线。没有日志的服务端先补日志没有度量就没有排查依据。检查超时配置。客户端超时设置太短上游处理慢一点就会断服务端 idle timeout 设置太短空闲连接会被回收长连接任务自然中断。检查心跳机制。WebSocket、TCP 长连接都需要心跳保活如果心跳间隔大于服务端空闲超时连接必然被回收。抓包确认。在授权范围内对链路做抓包看断线发生在哪一跳是 TCP FIN、RST 还是 TLS Alert。这一步能直接区分网络层问题和服务层问题。6.3 流式任务的重连与补偿策略即便前面都检查正常流式任务还是会断线。真正的工程能力体现在断线后的恢复策略上。一般做法是指数退避重连第一次 1 秒第二次 2 秒第三次 4 秒封顶 30 秒避免断线时客户端同时重连打爆服务端。断点续传或幂等处理如果流里包含一批任务重连后不要全部重放而是记录已处理位置只续传未完成的部分。超时分级连接超时、读写超时、整体任务超时分别设置不要所有超时共用一个值。告警与熔断连续重试失败要告警单一路由连续失败要触发熔断避免雪崩。另外如果你的部署环境涉及 Redis Stream 等消息组件要注意保持组件版本在官方支持的安全范围内。热搜里提到的redis stream nack 双重释放这类问题属于组件漏洞或稳定性缺陷方向。正确做法是在测试环境验证后按官方升级指引完成版本升级同时关闭不必要的公网暴露、开启密码认证和访问控制不依赖默认配置。涉及具体漏洞细节以官方安全公告为准不要在未授权的环境里模拟利用。7. 流式任务常见问题与工程最佳实践前面的报错排查是“出了事怎么修”这一节讲“怎么让事少发生”。结合流媒体 overlay 和通用流式开发的场景把最常见的坑和生产环境建议整理成清单。7.1 常见问题速查问题现象可能原因排查方式解决方案overlay 位置在不同分辨率下不对坐标写死没有用动态变量对比不同分辨率输出画面使用main_w、main_h、overlay_w、overlay_h相对坐标drawtext 时间戳不刷新把变量写成了常量字符串检查滤镜文本里的%{localtime}写法改用 FFmpeg 内置时间变量注意转义HLS 只有第一个分片生成不了后续-hls_time设置过小或编码器异常查看分片目录和 ffmpeg 日志增大分片时长确认编码器稳定推流任务偶发中断连接空闲被回收或网络抖动看服务端 idle 超时配置和抓包加心跳保活设置重连和退避策略Redis Stream 消费者拿不到新消息没有正确使用特殊 ID检查 XREADGROUP 参数新消息用历史回放才用0Java Stream 去重结果不符合预期equals/hashCode没重写或按错误字段排序打印 key 中间结果用自定义distinctByKey按业务主键去重7.2 流媒体 overlay 的工程建议生产环境处理画面叠加有几个细节需要提前规划设计不然后期维护成本很高叠加层与业务参数解耦。时间戳位置、字体大小、水印透明度这些应该放在配置文件或配置中心里不要写死在命令里。运营想改水印位置应该改配置而不是改代码。叠加素材先预处理。logo、角标这类素材在启动任务前先做尺寸归一化避免每条任务都做一次缩放浪费 CPU。视频处理任务要可重试。转码和推流任务必须保留输入源凭证和输出目标信息失败后能够从头或从断点重试且重复执行不会产生错误结果。任务日志带上 ID。每一个 ffmpeg 进程的日志、上下游回调、错误信息都要带上stream-408073756662300811_overlay这类任务 ID否则线上无法追踪一条流从采集到播放的完整路径。7.3 流式系统通用最佳实践无论是媒体流、Redis Stream 还是普通的长连接流以下原则是通用的超时参数分层连接超时、读取超时、处理超时分开设置。重试必须带退避避免断线雪崩。幂等优先于精准恢复能通过业务 ID 去重的任务不做复杂的状态恢复。连接池和消费组要有监控指标连接数、消息积压量、消费延迟、任务成功率都要可观测。变更前要在测试环境验证尤其是涉及 FFmpeg 滤镜链、Redis Stream 消费逻辑、连接池参数这类改动先在测试环境压一遍再上生产。涉及生产数据或线上服务变更时先备份配置、明确回滚方案、按最小权限原则操作。加一条验证命令变更后立即确认结果而不是等到用户反馈。此外stream recorder、录制插件这类工具属于外围采集设备不在核心处理链路里。如果你的目标是稳定的流式处理系统优先把拉流、处理、推流、监控这条主线做扎实再考虑外围录制和回放功能。8. 总结与后续学习方向回到stream-408073756662300811_overlay这个任务名。它真正提醒我们的不是某一项具体技术而是流式处理里的一个结构性事实stream 负责连接与传输overlay 负责数据加工两者必须协同工作。排查任务中断时先确认是哪一层断了设计业务功能时先确认数据和叠加层放在哪一层。这个思路对媒体流、Java Stream、Redis Stream 都成立。本文的核心内容可以概括为四点stream在媒体流、Java Stream、Redis Stream 中是三个完全不同的机制遇到报错先区分语境。overlay 在流媒体里是滤镜叠加核心是坐标、叠层顺序和动态素材处理。ffmpeg 的 overlay、drawtext、HLS 输出是流媒体开发的基本功建议把 4.2 到 4.4 的命令实际跑一遍。stream disconnected before completion系列错误的排查主线是看两端日志、查超时和心跳、必要时抓包然后建立重连与幂等机制。如果你的实际工作涉及视频处理下一步建议系统学习 FFmpeg 滤镜体系特别是filter_complex的完整用法如果偏向服务端开发可以深入研究 Spring Data Redis 的 Stream 消息监听机制以及消费组在消息消费异常时的 ACK 和重试策略。把这几个方向吃透再回到流式任务开发里你会发现自己不再被stream这个词吓住而是能快速判断它到底在描述哪一层问题可能出在哪里。