先看代码：
点击查看代码
def main():namefile = str(sys.argv[0]).split('.')[0]to_generate(arch, namefile + '.tex' )
原来的方法 namefile = str(sys.argv[0]).split('.')[0] 不行，核心原因是它依赖 sys.argv[0] 来获取当前脚本名称，但 sys.argv[0] 的值并非在所有情况下都可靠——它会受运行环境的影响，可能导致获取不到正确的脚本名，甚至得到空字符串。
关键问题：sys.argv[0] 的不确定性
sys.argv 是 Python 从命令行接收的参数列表，其中 sys.argv[0] 理论上是「当前执行的脚本路径/名称」，但实际值取决于如何运行脚本：
-
命令行运行（正常情况）
如果你在终端输入python my_script.py，sys.argv[0]会是my_script.py（或完整路径，如./my_script.py）。这时split('.')[0]能正确提取my_script。 -
IDE 运行（问题场景）
如果你用 VS Code、PyCharm 等 IDE 直接点击「运行」按钮，IDE 为了控制运行环境（比如传递额外参数、管理虚拟环境），可能会：- 给
sys.argv[0]传递空字符串''（部分 IDE 的默认行为）； - 传递 IDE 内部的临时路径（而非脚本本身的名称）；
- 传递脚本的完整路径（但包含特殊字符或多个
.，导致split出错）。
比如：
- 若
sys.argv[0]是空字符串''，split('.')会得到['']，取第 0 个元素还是空字符串； - 最终
namefile + '.tex'就变成了.tex。
- 给
-
其他异常情况
如果脚本被其他程序通过subprocess调用，且调用时没指定sys.argv[0]，也可能导致其值异常（比如为空或为调用程序的名称）。
总结：为什么原来的方法不可靠？
sys.argv[0] 是「命令行传入的脚本名」，而非「脚本本身的真实名称」——它依赖外部调用方式，环境变了，值就可能错。
而我们需要的是「当前脚本本身的文件名」，这只能通过 Python 内置的 __file__ 属性获取（__file__ 是 Python 解释器自动设置的，指向当前脚本的绝对路径，不受外部调用方式影响）。
因此，原来的方法因为依赖不稳定的 sys.argv[0]，在非命令行环境下会失效；而用 __file__ + os.path 处理，才能稳定获取正确的文件名。