诡异的问题花了我3个晚上都没有解决
最近像往常一样用go写服务端程序，写好了上传到线上服务器去测试一下，启动时，忽然报错：
1 | Trace/breakpoint trap (core dumped) |
通过AI得到的常见答案都没有解决问题：
- 从Mac系统编译Ubuntu系统，交叉编译的命令可能错误
- 目标服务器的芯片和编译的参数不正确
- 上传到服务器后，可执行文件的文件夹或文件的权限不够
以上都确认过，发现都没有问题，可问题依旧存在。
解决问题的契机
期间在qq群里也有热心群友帮忙编译发给我来做测试；也有朋友提醒我检查上传上去的文件的hash值是否和本地的一样；等等，还是好人多哦！因为上传群友的文件时，我顺手使用了ssh上传，结果发现可以。
于是我切换ftp上传为ssh上传自己的程序时，问题居然没有了。难道说，不同的上传方式还会有问题？
难道是FileZilla 上传文件到服务器，ftp上传时数据被修改了？
chatGPT 给了我一个解释
我把现象输入到chatGPT
我:
我发现使用filezilla ftp上传的不行，使用 FileZilla ssh 上传的可以 。 ftp的即使把用户和权限改成和ssh上传的一样也不行
AI:
这种情况下，可能是因为通过 FTP 上传的文件在某些细节上与 SSH 上传的文件有区别。 即使权限和用户一致，以下几个问题可能会导致二进制文件无法执行：
1. 文件传输模式
- FTP 支持 ASCII 模式 和 Binary 模式 传输。如果选择 ASCII 模式传输二进制文件，文件可能会被错误地转码，导致文件内容发生变化，从而无法正常执行。
- 解决方法：确保使用 Binary 模式 传输所有二进制文件。可以在 FileZilla 中设置传输模式为 Binary，具体步骤：
- 打开 FileZilla，点击菜单栏的 编辑 > 设置 > 传输。
- 选择 Binary 模式传输。
2. 文件完整性检查
- 在上传完成后，使用
md5sum或sha256sum来检查文件在本地和服务器上的哈希值是否一致，以确保文件传输过程中未发生损坏。 - 在本地计算哈希值：
1
md5sum go_test
- 在服务器上计算哈希值：
1
md5sum /data/www/go_test
3. FTP 客户端的特殊设置
- 某些 FTP 客户端在上传文件时可能会有特定的默认设置或优化选项，这些选项可能会更改文件的部分数据。确保在 FileZilla 中禁用任何会更改文件的优化选项，如压缩传输等。
4. 重新上传文件
- 确认使用 SSH 上传文件后可以正常运行，说明文件在服务器上没有其他环境问题。可以尝试删除原 FTP 上传的文件，并用 Binary 模式重新上传，避免因权限设置和传输模式引起的问题。
这样应该可以帮助解决由于 FTP 上传模式导致的二进制文件损坏问题。