本文详解在 Asterisk EAGI 模式下，Go 程序如何安全、非阻塞地读取标准输入（FD 3），指出直接使用 bufio.NewReaderSize + WriteTo 导致无限阻塞的根本原因，并提供基于 syscall.Read 的可靠实现方案。
本文详解在 asterisk eagi 模式下，go 程序如何安全、非阻塞地读取标准输入（fd 3），指出直接使用 `bufio.newreadersize` + `writeto` 导致无限阻塞的根本原因，并提供基于 `syscall.read` 的可靠实现方案。
在 Asterisk 的 EAGI（Enhanced AGI）模式中，Asterisk 会将音频流（RTP 解码后的 PCM 数据）、通道变量及控制指令通过标准输入（即文件描述符 3）传递给外部 Go 程序。许多开发者尝试沿用常规 I/O 模式——例如用 os.NewFile(3, "...") 创建文件对象，再套上 bufio.Reader 并调用 WriteTo() 向网络连接转发数据——但该方式极易陷入无限阻塞，且不报错。
根本问题在于：EAGI 的 FD 3 是一个面向字节流的、无消息边界的单向管道，其数据到达具有强实时性与间歇性（如静音期间无音频帧）。而 bufio.Reader.WriteTo() 会持续尝试读取直到 EOF 或写入失败，但 FD 3 永远不会自然关闭（Asterisk 进程存活期间保持打开），因此 WriteTo 将永远等待“更多数据”，造成挂起。
✅ 正确做法是绕过 bufio 抽象层，直接使用底层系统调用进行受控、非阻塞或带超时的读取：
package main
import (
"fmt"
"os"
"syscall"
"time"
)
func main() {
// 获取 EAGI 标准输入（FD 3）
eagiFD := uintptr(3)
// 分配缓冲区（建议 64KB，匹配 Asterisk 默认 PCM 帧大小）
buf := make([]byte, 64*1024)
for {
n, err := syscall.Read(int(eagiFD), buf)
if err != nil {
if err == syscall.EAGAIN || err == syscall.EWOULDBLOCK {
// 非阻塞模式下无数据可读，可短暂休眠或轮询
time.Sleep(10 * time.Millisecond)
continue
}
fmt.Fprintf(os.Stderr, "syscall.Read error: %v\n", err)
break
}
if n == 0 {
// 对端关闭（罕见，通常表示 Asterisk 异常终止）
fmt.Println("EAGI input closed")
break
}
// 成功读取 n 字节 PCM 数据（16-bit signed, 8kHz mono）
// 此处可处理音频、解析 EAGI headers 或转发至 conn
// 例如：conn.Write(buf[:n])
fmt.Printf("Read %d bytes from EAGI FD 3\n", n)
}
}⚠️ 关键注意事项：
-
不要依赖
/proc/self/fd/3路径打开文件：该路径在容器或某些受限环境中可能不可访问，且os.Open返回的*os.File会引入额外缓冲与 EOF 语义，与 EAGI 协议不兼容； -
务必验证 RTP 数据通路：如答案中所述，
syscall.Read阻塞往往不是代码问题，而是底层网络配置缺陷（如 SIP 通道未正确协商媒体、防火墙拦截 RTP、Asteriskrtp.conf配置错误等）。建议在 Asterisk CLI 中执行sip show channelstats或core show channels verbose，确认 RTP 收发状态为active且rxpackets > 0； -
推荐设置读取超时：若需更高可靠性，可结合
syscall.SetNonblock()或使用epoll/kqueue（通过golang.org/x/sys/unix）实现事件驱动读取； -
EAGI 数据格式：FD 3 首部为 ASCII 行（含
agi_channel,agi_language等变量），后接原始 PCM 流（默认 8kHz, 16-bit, mono），二者以空行分隔——解析时需先按行读取头信息，再切换为二进制读取。
总结：EAGI 编程要求对 Unix I/O 机制有清晰认知。放弃高级缓冲抽象，回归 syscall.Read 是保障实时性与稳定性的关键；同时，将调试重心从 Go 代码转向 Asterisk 媒体栈配置，才能真正解决“读不到数据”的本质问题。
