jsch连接sftp获取xml内容需直接使用channelsftp.get(string src)获取inputstream，而非依赖本地文件；注意字符集（如utf-8）、避免readallbytes导致oom，优先用sax/stax流式解析，并确认路径绝对性、权限及bom处理。
JSch连接SFTP后拿不到XML文件内容？先确认ChannelSftp.get()的用法
JSch里下载文件不是“读取字符串”，而是流式拉取，直接调用ChannelSftp.get(String src, String dst)会把XML写进本地文件，但如果你想要内存里的String或Document，得自己接管输入流。常见错误是调用get()后去读本地临时文件，结果发现文件空、编码乱、路径不存在——其实根本没等它写完，或者没关流。
-
ChannelSftp.get(String src)返回的是InputStream，这才是你该用的入口，别漏掉这个重载 - XML文件若含中文，务必指定字符集（如
new String(bytes, "UTF-8")），JSch默认不处理编码 - 别用
FileInputStream去读刚get()出来的本地路径——除非你明确调用了双参数版本并确保文件已落盘且IO完成 - 示例：获取流后转为字符串：
InputStream is = sftpChannel.get("/data/config.xml");<br>String xmlStr = new String(is.readAllBytes(), "UTF-8");
下载大XML时内存爆了？用InputStream配合SAX或StAX解析
把几MB甚至上百MB的XML全读进byte[]再丢给DOM解析器，是Java里最典型的OOM诱因。JSch的get()返回的InputStream是阻塞式、可标记的，完全适配SAX或XMLStreamReader这种边读边处理的模式。
- 不要调
is.readAllBytes()或IOUtils.toString(is)——这是给小配置文件用的 - SAX适合只关心部分标签的场景，比如只提取
<host></host>和<port></port>；StAX更灵活，支持跳过无关节点 - 注意：JSch的
InputStream不支持mark()/reset()多次回溯，SAX/StAX本身也不依赖这个 - 示例（StAX）：
XMLInputFactory f = XMLInputFactory.newInstance();<br>XMLStreamReader r = f.createXMLStreamReader(sftpChannel.get("/big-report.xml"));
报错SftpException: No such file但路径明明存在？检查SFTP路径格式和权限
SFTP路径不是Linux shell路径，不继承当前工作目录，所有路径都是绝对路径（以/开头），且区分大小写。更隐蔽的问题是：用户有登录权限 ≠ 有读取目标目录下文件的权限，尤其当XML在/var/www/xml/这类非家目录时。
- 先用
sftpChannel.ls("/path/to")确认目录存在且能列出内容，别只靠肉眼判断路径对不对 - 如果路径含空格或括号，不用URL编码，但要用双引号包裹整个路径传给
get()（实际不用，JSch内部不解析URL，只是字面量传递） - 某些SFTP服务器（如旧版ProFTPD）对
stat调用敏感，ls()失败不等于get()一定失败，可跳过ls直接get()并捕获异常 - 错误信息
SftpException: No such file也可能是权限不足，而非文件真不存在——服务端常统一返回这个码
为什么下载下来的XML打开全是乱码或头部多出\x00？检查传输模式和BOM
JSch默认走二进制传输，不会动原始字节，所以XML里的UTF-8 BOM（\uFEFF）或Windows换行符\r\n都会原样保留。问题往往出在你后续处理时假设它是纯文本流，却忽略了BOM导致解析器误判编码，或没过滤掉不可见控制字符。
立即学习“Java免费学习笔记（深入）”；
- 用
hexdump -C config.xml | head看前几个字节：如果是00 00 fe ff，说明被错误地当成了UTF-16BE写入 - 读取后手动剥离BOM：
if (xmlStr.startsWith("\uFEFF")) { xmlStr = xmlStr.substring(1); } - 避免用
String.getBytes()来回转换——它依赖系统默认编码，CI环境可能崩，始终显式传"UTF-8" - 如果XML声明是
<?xml version="1.0" encoding="GBK"?>，那你必须用GBK解码流，不能硬上UTF-8
