这种情况我碰到过好几次，通常是以下几个常见原因导致的，我帮你逐一拆解：

1. 异常类导入不完整或错误 #

你代码里的from minio.error import [...], SignatureDoesNotMatch, [...]用了省略号，大概率是没有正确把SignatureDoesNotMatch导入到当前代码的作用域中。如果导入语句有问题，except SignatureDoesNotMatch实际上捕获的不是MinIO抛出的那个异常类，自然就会漏抓，让异常直接向上抛出。

解决办法：
直接明确列出所有需要的异常类，确保导入正确：

from minio.error import (
    SignatureDoesNotMatch,
    ResponseError,
    InvalidAccessKeyId,
    InvalidArgument,
    InvalidArgumentError
)

2. MinIO客户端版本差异导致异常类路径变化 #

不同版本的MinIO Python客户端，异常类的定义可能有变动。比如在某些新版本中，SignatureDoesNotMatch可能不再直接放在minio.error模块下，或者被重命名、归类到其他子模块里了。

验证方法：
你可以临时修改代码，捕获所有异常并打印它的类信息，确认实际抛出的异常的完整路径：

def login(self):
    try:
        self.user = Minio(MINIO_CONFIG['MINIO_ENDPOINT'],
                         access_key=self.username,
                         secret_key=self.password,
                         secure=MINIO_CONFIG['MINIO_SECURE'])
        return {"msg":"User is now logged in", "status": "OK"}
    except Exception as err:
        print(f"抛出的异常类: {type(err)}")  # 输出异常的完整类路径
        raise  # 重新抛出异常，不影响原有流程

根据输出的类路径，调整你的导入语句即可。

3. 异常并非在客户端初始化时抛出（小概率） #

有些MinIO客户端版本中，初始化Minio对象本身不会立即发起请求验证凭证，而是在第一次执行实际操作（比如list_buckets()）的时候才会触发签名验证。如果你的异常是在后续操作中抛出的，但try块只包裹了初始化代码，那自然捕获不到。

验证方法：
在初始化客户端后立即添加一个简单的验证操作，把它也包含在try块里：

def login(self):
    try:
        self.user = Minio(MINIO_CONFIG['MINIO_ENDPOINT'],
                         access_key=self.username,
                         secret_key=self.password,
                         secure=MINIO_CONFIG['MINIO_SECURE'])
        self.user.list_buckets()  # 强制发起请求验证凭证
        return {"msg":"User is now logged in", "status": "OK"}
    # 后续的except语句不变

如果异常是在这里抛出的，那你只需要把操作代码也纳入try块即可。

4. 异常继承关系的小坑（已排除，但可确认） #

虽然你的代码里捕获顺序是对的（先捕获具体的SignatureDoesNotMatch，再捕获宽泛的ResponseError），但可以确认一下SignatureDoesNotMatch是否是ResponseError的子类：

print(issubclass(SignatureDoesNotMatch, ResponseError))

如果返回True，那你的捕获顺序没问题；如果返回False，那也不影响，因为你已经单独捕获了它。

总结 #

最可能的原因还是异常导入不正确，先检查你的导入语句，确保SignatureDoesNotMatch被正确导入到当前作用域中，这应该能解决你的问题。

内容的提问来源于stack exchange，提问作者csymvoul