遇到这种模块重名的导入坑确实头疼，尤其是维护旧项目不想大面积改代码的情况下。下面给你几个可行的解决方案，按推荐程度排序：

1. 启用绝对导入（Python 2.x 必备，Python 3.x 可选增强） #

如果你的项目还在使用Python 2，这个方法最直接。在payments/models.py的最顶部（任何其他导入之前）添加这一行：

from __future__ import absolute_import

这行代码会强制Python使用绝对导入规则：当你写from fancymodule import ApiClient时，Python会优先去sys.path里的全局位置（比如pip安装的site-packages）找模块，而不是当前payments包下的同名子模块。

如果是Python 3，虽然默认就是绝对导入，但有时候旧项目的兼容代码可能导致行为异常，加上这行也能确保导入行为符合预期。

2. 调整sys.path的优先级 #

如果上面的方法不生效，你可以手动调整Python的模块搜索路径，让全局安装的fancymodule所在目录排在项目目录前面。

你可以在项目的manage.py或者settings.py的最开头添加这段代码：

import sys
from distutils.sysconfig import get_python_lib

# 获取全局site-packages目录路径
site_packages_path = get_python_lib()
# 将site-packages移到sys.path最前端，确保优先搜索全局模块
if site_packages_path not in sys.path or sys.path.index(site_packages_path) != 0:
    sys.path.insert(0, site_packages_path)

这样Python会先搜索全局的site-packages目录，找到pip安装的fancymodule，而不是项目内的同名模块。

注意：这个方法要谨慎使用，测试时要确认不会影响Django自身模块、其他app模块的正常导入。

3. 重命名项目内的同名模块（终极备选） #

如果上面的方法都有问题，最彻底的解决方式就是把payments/fancymodule重命名为其他名字（比如payments/internal_fancymodule），然后把项目内所有引用它的地方改成from payments.internal_fancymodule import ...。虽然需要改一些代码，但能彻底避免重名冲突，适合长期维护的项目。

验证导入是否正确 #

不管用哪种方法，你都可以在payments/models.py里加一行代码验证导入的模块是否正确：

from fancymodule import ApiClient
print(ApiClient.__module__)

运行Django项目后，如果输出是fancymodule（而不是payments.fancymodule），就说明导入的是pip安装的模块了。

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