没想到本地保存的fasta文件上传到linux上还会引起一些额外的字符统计。一开始我以为是我本地弄错了，又重新跑了一遍获得fasta文件的过程，也去blast比对了，blast上统计的数值为156662，上传到服务器上，用grep -v "^>" 1.fasta | tr -d "\n" | wc -c 统计结果却变成了158901，这怎么多出来2239个碱基？用less查看也没看出来啥问题。而在ncbi上下载的fasta文件直接上传到服务器，统计的结果却是对的。导致我后续比对就一直报错，说有一段匹配不到。我又重新生成了fasta文件，把序列复制到word中用字数统计也还是156662，这真的就奇了怪了。问了AI，说可能是文件格式和编码的问题，用file命令检查一下文件编码，一查果然出问题了！
file ref.fasta
ref.fasta: ASCII text
file 1.fasta
1.fasta: ASCII text, with CRLF line terminators
说明文件被识别为ASCII文本，并且使用了CRLF行终止符。这通常是在Windows系统上生成的文件所使用的行终止符，表现为\r\n。在Linux环境下，这种行终止符可能会引起一些额外的字符统计。
找到原因了，那就把文件的CRLF行终止符转成linux的LF行终止符（即单个\n）：dos2unix 1.fasta
再跑grep -v "^>" 1.fasta | tr -d "\n" | wc -c 结果就是156662了。
终于搞定，又长教训了，文件编码会影响字符统计。