🔎大家好，我是ZTLJQ，希望你看完之后，能对你有所帮助，不足请指正！共同学习交流

📝个人主页－ZTLJQ的主页

🎁欢迎各位→点赞👍 + 收藏⭐️ + 留言📝​

📣系列专栏 - Python从零到企业级应用：短时间成为市场抢手的程序员

✔说明⇢本人讲解主要包括Python爬虫、JS逆向、Python的企业级应用

如果你对这个系列感兴趣的话，可以关注订阅哟👋

一、基础语法与核心概念

1.1 可变对象与不可变对象的区别

原题：

a = 256
b = 256
print(a is b)  # True

a = 257
b = 257
print(a is b)  # False

为什么上述代码在处理256和257时输出不同？

解析思路：

这道题考察的是Python的整数缓存机制。Python在CPython解释器中，对-5到256之间的整数进行了缓存优化。当创建这些范围内的整数时，Python会直接使用缓存中的对象，因此is比较会返回True。但超出这个范围的整数（如257），Python会为每个变量创建独立的对象，因此is比较返回False。

关键结论 (Key Takeaway)

CPython对-5到256之间的整数进行了缓存优化。在此范围内的整数使用缓存对象，`is`比较返回True；超出此范围则创建独立对象，`is`比较返回False。

自创题：

s1 = "Python"
s2 = "Python"
s3 = "Python is fun"
s4 = "Python is fun"

print(s1 is s2)  # True
print(s3 is s4)  # False

s5 = sys.intern("Python is fun")
s6 = sys.intern("Python is fun")
print(s5 is s6)  # ?

s7 = "Py"
s8 = "Py"
s9 = "Pyth"
s10 = "Pyth"

print(s7 is s8)  # ?
print(s9 is s10)  # ?

解析思路：

这道题考察的是Python字符串驻留机制。Python对短字符串（长度≤20且仅包含字母、数字、下划线）和编译时确定的字符串进行了驻留优化。但较长或包含特殊字符的字符串不会被自动驻留，因此is比较返回False。sys.intern()可以强制将字符串驻留到小数据池中，使is比较返回True。对于长度为2的字符串"Py"，Python会自动驻留，因此is比较返回True；而长度为4的"Pyth"则不会被自动驻留，因此is比较返回False。

字符串驻留规则

自动驻留 (编译时)

短字符串 (长度 ≤ 20) 且仅含字母、数字、下划线，如 "Py"。

自动驻留 (运行时)

部分常见字符串，如函数名、变量名等。

强制驻留

使用 sys.intern() 函数，可驻留任意字符串。

二、高级特性与设计模式

2.1 装饰器的实现原理

原题：

手写一个带参数的装饰器，实现日志功能，可以指定日志级别。

参考解答：

def log_with_level(level):
    def decorator(func):
        def wrapper(*args, **kwargs):
            print(f"[{level}] Calling {func.__name__}")
            return func(*args, **kwargs)
        return wrapper
    return decorator

@log_with_level("INFO")
def add(a, b):
    return a + b

add(1, 2)
# 输出: [INFO] Calling add

解析思路：

这道题考察的是装饰器的嵌套结构和闭包变量作用域。带参数的装饰器需要三层嵌套函数：外层函数接收装饰器参数，中间层函数接收被装饰函数，内层函数（wrapper）实现装饰逻辑并调用原函数。闭包变量保留了装饰器参数level，使得不同函数可以应用不同级别的日志。

概念模型 (Conceptual Model)

外层函数

(接收装饰器参数)

中间层函数

(接收被装饰函数)

内层函数 (Wrapper)

(执行装饰逻辑)

带参数的装饰器结构

自创题：

实现一个类装饰器，支持在运行时动态启用或禁用装饰功能。当装饰器被禁用时，被装饰函数应直接返回原函数的结果，不执行任何附加逻辑。

参考解答：

class DynamicDecorator:
    def __init__(self, enabled=True):
        self.enabled = enabled

    def __call__(self, func):
        def wrapper(*args, **kwargs):
            if self.enabled:
                print(f"Decorator logic for {func.__name__}")
                result = func(*args, **kwargs)
                print(f"Result: {result}")
                return result
            else:
                return func(*args, **kwargs)
        return wrapper

# 使用示例
decorator = DynamicDecorator.enabled = False

@decorator
def multiply(a, b):
    return a * b

print(multiply(3, 4))  # 应输出12，不执行装饰器逻辑

解析思路：

这道题考察的是类装饰器的实现原理和动态行为控制。类装饰器通过实现__call__方法使其实例可调用。通过设置enabled属性，可以在运行时控制装饰器功能的开关。当enabled为True时，wrapper函数会执行装饰逻辑；当enabled为False时，wrapper直接返回原函数的结果，不执行任何附加操作。这种方式提供了比传统装饰器更灵活的行为控制能力，适合需要动态调整功能的场景。

三、并发编程与性能优化

3.1 GIL对多线程的影响

原题：

解释Python中的GIL是什么？它对多线程编程有什么影响？

解析思路：

GIL是全局解释器锁（Global Interpreter Lock），是CPython解释器中的一个机制，确保同一时刻只有一个线程执行Python字节码。它带来的影响包括：

• CPU密集型任务：多线程性能可能不如单线程，因为GIL限制了真正的并行
• I/O密集型任务：GIL影响较小，因为I/O操作会释放GIL
• 多进程解决方案：可以通过multiprocessing模块绕过GIL限制

关键结论 (Key Takeaway)

GIL（全局解释器锁）是CPython的核心机制，它保证同一时刻只有一个线程执行字节码。这使得多线程在CPU密集型任务中无法真正并行，但在I/O密集型任务中影响较小。

自创题：

import asyncio
import time

async def cpu_bound_task(n):
    # 模拟CPU密集型操作
    total = 0
    for _ in range(n):
        total += _ * _ * _
    return total

async def io_bound_task(url):
    # 模拟I/O密集型操作
    await asyncio.sleep(1)
    return f"Data from {url}"

async def main():
    tasks = [
        cpu_bound_task(10**7),
        cpu_bound_task(10**7),
        io_bound_task("https://api.example.com/data1"),
        io_bound_task("https://api.example.com/data2")
    ]
    start = time.time()
    await asyncio.gather(*tasks)
    print(f"Total time: {time.time() - start:.2f} seconds")

asyncio.run(main())

假设上述代码在单核CPU和多核CPU上运行，执行时间会有明显差异吗？为什么？

解析思路：

这道题考察的是协程与GIL的关系。虽然asyncio提供了异步编程模型，但它仍然运行在单个线程中，受GIL限制。对于CPU密集型任务（如cpu_bound_task），即使使用asyncio.gather并发执行，由于GIL的存在，它们实际上会在事件循环中串行执行，无法利用多核CPU并行计算。因此，无论在单核还是多核CPU上运行，执行时间不会有明显差异。

性能陷阱 (Performance Pitfall)

对于CPU密集型任务，即使使用 `asyncio.gather` 并发执行，由于GIL的存在，它们实际上会在事件循环中串行执行，无法利用多核CPU并行计算，因此执行时间不会有明显差异。

解决方案：

import asyncio
import time
from multiprocessing import Pool

def cpu_bound_task(n):
    total = 0
    for _ in range(n):
        total += _ * _ * _
    return total

async def io_bound_task(url):
    await asyncio.sleep(1)
    return f"Data from {url}"

async def run_in_process_pool(process_pool, func, *args):
    loop = asyncio.get_event_loop()
    return await loop.run_in_executor(process_pool, func, *args)

async def main():
    loop = asyncio.get_event_loop()
    process_pool = Pool(processes=2)

    tasks = [
        run_in_process_pool(process_pool, cpu_bound_task, 10**7),
        run_in_process_pool(process_pool, cpu_bound_task, 10**7),
        io_bound_task("https://api.example.com/data1"),
        io_bound_task("https://api.example.com/data2")
    ]

    start = time.time()
    await asyncio.gather(*tasks)
    print(f"Total time: {time.time() - start:.2f} seconds")

    process_pool.close()
    process_pool.join()

asyncio.run(main())

通过将CPU密集型任务放入multiprocessing池中执行，可以绕过GIL限制，充分利用多核CPU性能。I/O密集型任务仍可通过协程实现高效并发。

四、内存管理与对象模型

4.1 深拷贝与浅拷贝的区别

原题：

import copy

original = [[1, 2], [3, 4]]
shallow_copy = original.copy()
deep_copy = copy.deepcopy(original)

shallow_copy[0][0] = 99
deep_copy[0][0] = 100

print(original)  # [[99, 2], [3, 4]]
print(deep_copy)  # [[1, 2], [3, 4]]

为什么修改shallow_copy不会影响deep_copy，但会影响original？

解析思路：

这道题考察的是Python中对象引用与拷贝机制。浅拷贝（list.copy()或copy.copy()）只复制对象的第一层引用，嵌套对象仍然共享内存地址。深拷贝（copy.deepcopy()）会递归复制所有层级的对象，确保原始对象和拷贝对象完全独立。

拷贝机制对比

浅拷贝 (Shallow Copy)

只复制第一层引用

→

嵌套对象共享内存

深拷贝 (Deep Copy)

递归复制所有层级

→

原始与拷贝完全独立

自创题：

import copy

class Person:
    def __init__(self, name, address):
        self.name = name
        self.address = address

    def __repr__(self):
        return f"Person({self.name!r}, {self.address!r})"

p1 = Person("Alice", ["Main St", 123])
p2 = Person("Bob", ["Broadway", 456])
original = [p1, p2]

# 实现自定义的浅拷贝方法
# 你的代码

# 测试代码
copy1 =浅拷贝(original)
copy2 = copy.copy(original)

original[0].address[0] = "Wall St"
original[0] = Person("Alice", ["Wall St", 123])

print("Original:", original)
print("Copy1:", copy1)
print("Copy2:", copy2)

输出结果应为：

Original: [Person('Alice', ['Wall St', 123]), Person('Bob', ['Broadway', 456])]
Copy1: [Person('Alice', ['Wall St', 123]), Person('Bob', ['Broadway', 456])]
Copy2: [Person('Alice', ['Main St', 123]), Person('Bob', ['Broadway', 456])]

解析思路：

这道题考察的是浅拷贝的实现原理和不同对象类型的引用行为。列表的浅拷贝会复制列表本身，但列表中的元素仍是原对象的引用。对于可变对象（如列表），修改元素内容会影响所有引用该元素的对象；但对于不可变对象（如字符串），直接赋值新对象不会影响拷贝。在自定义浅拷贝方法中，需要遍历原列表，创建新列表实例，并复制每个元素的引用。

参考解答：

def 浅拷贝(original_list):
    new_list = []
    for obj in original_list:
        new_obj = type(obj)(obj.name, obj.address.copy())
        new_list.append(new_obj)
    return new_list

# 浅拷贝的另一种实现方式
def 浅拷贝_v2(original_list):
    return [type(obj)(p.name, p.address.copy()) for p in original_list]

五、数据结构与算法

5.1 字典的哈希冲突处理

原题：

解释Python字典如何处理哈希冲突？为什么Python 3.6+的字典采用更紧凑的存储结构？

解析思路：

Python字典使用开放寻址法处理哈希冲突。当两个键的哈希值映射到同一个槽位时，字典会通过线性探测（在Python 3.7之前）或更高效的二次探测（在Python 3.7及之后）寻找下一个空闲槽位。Python 3.6引入了有序字典，存储结构从链表+数组改为更紧凑的连续内存布局，提高了访问效率和内存利用率。

字典存储结构演进

< Python 3.6

采用链表+数组的存储结构，内存利用率较低，且不保证元素的插入顺序。

Python 3.6+

引入有序字典，采用更紧凑的连续内存布局，提高了访问效率和内存利用率，并保证了元素的插入顺序。

自创题：

实现一个简化版的开放寻址哈希表，支持插入、查询和删除操作。当发生哈希冲突时，使用线性探测法寻找下一个空闲槽位。

class SimpleHash:
    def __init__(self, size=8):
        self.size = size
        self.keys = [None] * size
        self.values = [None] * size

    def hash(self, key):
        return hash(key) % self.size

    # 实现插入、查询和删除方法
    # 你的代码

# 测试代码
hash_table = SimpleHash(5)
hash_table.insert("a", 1)  # hash值为0
hash_table.insert("f", 2)  # hash值为0，发生冲突
print(hash_table.query("a"))  # 应返回1
print(hash_table.query("f"))  # 应返回2
hash_table.delete("a")
print(hash_table.query("a"))  # 应返回None

解析思路：

这道题考察的是哈希表的底层实现原理。开放寻址法处理哈希冲突的核心是将冲突的键值对存储在表中的其他位置。线性探测法通过在哈希冲突时，依次检查下一个槽位，直到找到空闲位置。实现时需要注意：

• 插入：计算初始哈希值，若冲突则使用探测序列寻找空闲槽位
• 查询：计算初始哈希值，若键不存在则按探测序列查找可能的冲突键
• 删除：不能简单地将槽位置为None，否则会影响后续的探测逻辑，通常使用"删除标记"（如sentinel对象）表示已删除的槽位

六、框架与库的高级使用

6.1 Django猴子补丁的应用

原题：

from django.db import models

class User(models.Model):
    name = models.CharField(max_length=100)
    email = models.EmailField()

def custom_save(self):
    print("Custom save logic")
    super().save()

User.save = custom_save

上述代码是否会对Django的模型保存逻辑产生影响？如果会产生影响，这种影响是全局性的还是局部性的？

解析思路：

这道题考察的是猴子补丁在Django框架中的应用。上述代码会修改User模型的save方法，添加自定义逻辑。这种修改是全局性的，所有User模型的实例都会使用修改后的save方法。猴子补丁是Python的动态特性，允许在运行时修改类或模块的方法，但需要谨慎使用，因为它会影响所有使用该模型的代码路径。

关键结论 (Key Takeaway)

猴子补丁（Monkey Patching）是Python的动态特性，允许在运行时修改类或模块的方法。但需要谨慎使用，因为这种修改是全局性的，会影响所有使用该模型的代码路径。

自创题：

在Django项目中，有一个国际化需求：处理德语等含有特殊字符的文本时，需要更智能地处理URL生成。Django的slugify()函数默认无法正确处理这些特殊字符。请通过猴子补丁技术，使用awesome-slugify库优化Django的slugify()函数，使其能正确处理多语言字符。

解析思路：

这道题考察的是猴子补丁在Django框架中的高级应用场景。需要了解：

• Django的slugify()函数位置：位于django.utils.text模块中
• awesome-slugify库的功能：提供了更强大的多语言URL生成支持
• 猴子补丁的实现方式：在Django项目启动时，动态替换Django的slugify()函数

参考解答：

# 在项目的__init__.py或自定义的patches.py文件中添加以下代码
from django.utils.text import slugify as original_slugify
from slugify import slugify as improved_slugify  # awesome-slugify库的导入方式

def monkey_patch_slug():
    # 保留原始函数的__name__和__doc__属性，以便在调试时识别
    improved_slugify.__name__ = "patched_slugify"
    improved_slugify.__doc__ = "Patched slugify for better multilingual support"

    # 替换Django的slugify函数
    from django.utils.text import slugify
    import types
    module = sys.modules['django.utils.text']
    module.slugify = types.FunctionType(improved_slugify.__code__, module.__dict__, "slugify", closure=improved_slugify.__closure__)

# 在项目入口文件中调用猴子补丁
from .guerrilla_patches import monkey_patch_slug
monkey_patch_slug()

注意事项：

• 猴子补丁应尽量在项目启动时应用，以确保所有后续代码使用的是修改后的函数
• 在多线程或多进程环境下，猴子补丁的行为可能不一致，需要谨慎处理
• 建议使用@wraps装饰器保留原始函数的元数据，提高代码可维护性