AudioSystem.getAudioInputStream抛UnsupportedAudioFileException主因是误将麦克风TargetDataLine等原始PCM流当作文件传入，因其无WAV/AIFF等文件头；正确做法是直接调用line.read()读取字节。
AudioSystem.getAudioInputStream 为什么总抛 UnsupportedAudioFileException
常见原因是传入了不支持的音频格式或设备流。Java Sound API 的 AudioSystem.getAudioInputStream 只能处理已知编码的文件（如 WAV、AIFF），**不能直接用于麦克风实时流**。试图对 TargetDataLine 调用它会失败——因为麦克风数据是原始 PCM 流，没有文件头。
正确做法是跳过这一步，直接从 TargetDataLine 读取字节：
AudioFormat format = new AudioFormat(
AudioFormat.Encoding.PCM_SIGNED,
44100.0f, // sample rate
16, // sample size in bits
2, // channels
4, // frame size
44100.0f, // frame rate
false // big endian
);
DataLine.Info info = new DataLine.Info(TargetDataLine.class, format);
TargetDataLine line = (TargetDataLine) AudioSystem.getLine(info);
line.open(format);
line.start(); // 开始采集
byte[] buffer = new byte[4096];
int bytesRead;
while (recording) {
bytesRead = line.read(buffer, 0, buffer.length); // 直接读，别 wrap 成 InputStream
// 处理 buffer 中的 PCM 数据
}
如何避免 LineUnavailableException 启动失败
这个异常几乎总是因为：同一时间有其他程序占用了麦克风（如 Zoom、Teams、系统录音机），或 JVM 没有权限访问音频设备（尤其在 macOS 或 Linux 的 sandbox 环境中）。
- 检查是否已有
TargetDataLine在运行：调用前先line.isRunning()或确保close()旧实例 - 显式指定设备而非依赖默认：用
AudioSystem.getMixer(null)列出所有混音器，挑出带"Microphone"或"Capture"字样的 - Linux 下可能需加入
audio用户组；macOS 需在「系统设置 → 隐私与安全性 → 麦克风」中允许 Java 应用
实时录音时 CPU 占用飙升，怎么压低延迟又不卡顿
核心矛盾在于缓冲区大小：buffer 太小 → 频繁 read() 调用，上下文切换多；太大 → 延迟高、响应滞后。4096 字节（约 23ms @ 44.1kHz/16bit/stereo）是较稳妥起点。
更关键的是别在 read() 循环里做重操作：
- 不要在循环内新建对象（如
new ByteArrayOutputStream()） - 避免同步 IO（如边录边写磁盘 WAV 文件）——改用双缓冲队列 + 独立写线程
- 若需实时 FFT 或降噪，优先用
float[]批量转换（用AudioFormat的getSampleSizeInBits()和isBigEndian()正确解析 PCM）
保存为 WAV 文件必须手动写 header
Java Sound API 不提供“把 raw PCM 流自动封装成 WAV”的工具类。WAV 是 RIFF 容器格式，header 固定 44 字节，含采样率、位深、声道数等字段。漏写或写错会导致播放器无法识别。
最简 header 构造逻辑（适用于 PCM_SIGNED, 16-bit, stereo）：
public static byte[] wavHeader(int byteRate, int audioDataLength) {
byte[] header = new byte[44];
// "RIFF"
header[0] = 'R'; header[1] = 'I'; header[2] = 'F'; header[3] = 'F';
// file size = 36 + audioDataLength
writeInt(header, 4, 36 + audioDataLength);
// "WAVE"
header[8] = 'W'; header[9] = 'A'; header[10] = 'V'; header[11] = 'E';
// "fmt "
header[12] = 'f'; header[13] = 'm'; header[14] = 't'; header[15] = ' ';
// format chunk size = 16
writeInt(header, 16, 16);
// format = 1 (PCM)
writeShort(header, 20, (short) 1);
// channels = 2
writeShort(header, 22, (short) 2);
// sampleRate = 44100
writeInt(header, 24, 
byteRate / 4); // 注意：byteRate = sampleRate * channels * bitsPerSample/8
// byteRate
writeInt(header, 28, byteRate);
// blockAlign = channels * bitsPerSample/8
writeShort(header, 32, (short) 4);
// bitsPerSample = 16
writeShort(header, 34, (short) 16);
// "data"
header[36] = 'd'; header[37] = 'a'; header[38] = 't'; header[39] = 'a';
// subchunk2Size = audioDataLength
writeInt(header, 40, audioDataLength);
return header;
}
header 写完后，再追加原始 PCM byte[] ——顺序不能反，长度不能错。
真实项目里最容易被忽略的，是不同平台对 TargetDataLine 缓冲行为的差异：Windows 上默认 buffer 可能偏大，Linux ALSA 有时会静默丢帧，而 macOS CoreAudio 对 open() 的 millisecondTimeout 参数更敏感。别假设一次参数适配全平台。
