AWS API Gateway+Lambda下调用pymysql conn.close()为何触发CORS错误？

架构老林

2026-10-25

问题核心根因

你遇到的“调用conn.close()就报CORS错误、注释就正常”的现象，本质和API Gateway的CORS配置没有直接关系，核心触发逻辑有两点：

触发异常分支后响应缺失CORS头
当你执行conn.close()时，因为conn是Lambda全局作用域初始化、跨热实例复用的PyMySQL连接，关闭操作很容易触发连接相关的异常（比如连接已经被数据库服务端超时回收、套接字已经关闭的情况下重复调用close抛错）。这时候代码会跳转到except分支执行500返回，但这个分支的返回结构里完全没有配置CORS相关的响应头。浏览器对跨域响应的校验逻辑是只要响应缺失允许跨域的头信息，不管返回的是200还是500，都会直接抛出CORS错误，不会展示真实的状态码和错误内容，让你误以为是CORS规则配置错了。
手动关闭Lambda全局复用的数据库连接完全没必要
Lambda是短生命周期的事件驱动运行环境，当实例被回收时，进程内所有的TCP连接都会被操作系统自动清理，不需要在业务代码里手动调用close。手动close全局连接不仅会引入额外的异常触发点，还会导致后续复用这个实例的请求拿到一个已经关闭的连接，触发更多数据库报错。

对应修复方案

彻底从业务代码里移除conn.close()的调用逻辑，不要手动管理全局复用的数据库连接

抽离公共的响应头配置，保证正常返回和异常返回的所有场景下，都带上完整的CORS头信息，避免浏览器把缺头的异常响应误判为CORS错误
调整后的参考代码如下：

# 全局初始化的连接对象，不需要业务代码手动关闭
conn = pymysql.connect(...)

def lambda_handler(event, context):
    sg_dict = {}
    # 统一抽取公共响应头，所有返回场景复用
    common_headers = {
        'Access-Control-Allow-Headers': 'Content-Type',
        'Access-Control-Allow-Origin':  '*',
        'Access-Control-Allow-Methods': 'GET'
    }
    try:
        cur = conn.cursor()
        sg_dict = sg_select_query(cur)
        if sg_dict != {}:
            sg_dict = ec2_select_query(cur, sg_dict)
        
        return {
            'statusCode': 200,
            'headers': common_headers,
            'body': json.dumps(sg_dict)
        }
    except Exception as e:
        import traceback
        print(traceback.format_exc())
        # 异常返回也要携带完整CORS头，避免浏览器误报
        return {
            'statusCode': 500,
            'headers': common_headers,
            'body': json.dumps({"error": str(e)})
        }

针对全局连接可能被数据库服务端超时断开的问题，不要靠手动close解决，要在执行数据库操作前加活性校验：比如执行查询前判断conn.open状态，如果连接不可用就重新初始化连接，不需要手动关闭旧连接。

补充说明：AWS HTTP API模式本身内置了CORS预检请求的处理能力，但如果你的自定义响应（尤其是异常分支的响应）漏配了跨域头信息，预检请求通过后的实际响应依然会被浏览器拦截，抛出统一的CORS报错提示，这也是这类问题具备强迷惑性的原因。

内容的提问来源于stack exchange，提问作者gangmin.chun