JZX 轻语

记录一次使用 WinDbg 排查程序退出时 GDI+ 对象内存二次释放问题

Fri, 26 Jun 2026 00:00:00 +0000

背景

一个单例持有一个 GDI+ 对象的指针。在其生命周期末期（应用程序退出阶段、单例析构过程中）对该指针执行 delete 时发生 crash，报错 Access violation - code c0000005。

怀疑是二次释放导致的 crash，但排查后发现该指针此前并未被显式 delete，问题显得很诡异。

排查过程

首先在VS/WinDbg中对crash现场进行分析：delete 这个指针的时候，该内存区域确实已经失效（全部为?）。
第一次尝试：在 Visual Studio 中对该指针对应的内存地址设置数据断点，但未能命中。
第二次尝试：使用 WinDbg 调试，输入命令 ba w4 <指针地址> 试图对该内存的写操作设置断点，但仍未命中，最终还是触发 crash。
经过两次尝试，怀疑并非是自己的代码写坏了内存，更可能是堆内存已被回收。（很多堆分配器会在用户可见内存前后放置元数据，并不会真正改写被监控的内存区域，因此数据断点无法命中；但后续执行 delete 时，堆管理器会发现堆的元数据已被破坏，从而触发 crash）

在 VS 中查看 delete operator 的定义后发现，它并不是 CRT 自带的 operator，而是由 GDI+ 自行定义的，最终会调用其内部的 GdipFree(void* ptr) 函数。

 class GdiplusBase
 {
 public:
     void (operator delete)(void* in_pVoid)
     {
        DllExports::GdipFree(in_pVoid);
     }
     void* (operator new)(size_t in_size)
     {
        return DllExports::GdipAlloc(in_size);
     }
     void (operator delete[])(void* in_pVoid)
     {
        DllExports::GdipFree(in_pVoid);
     }
     void* (operator new[])(size_t in_size)
     {
        return DllExports::GdipAlloc(in_size);
     }
 };

第三次尝试：在 WinDbg 中用 x Gdiplus!* 找到 GdipFree 的符号，并用 bp 为其设置断点，但在 crash 之前还是未命中。由此猜测：程序退出前，GDI+ 的某个阶段可能会统一释放其申请的所有堆内存。

第四次尝试：使用 !address <指针值> 获取对应内存页的信息，并尝试在 Base Address 上设置数据断点。但仍未命中，程序依旧直接 crash；且 crash 后该页已被回收。

释放前的内存页信息：

 0:008> !address 20227690810
    
                                         
 Mapping file section regions...
 Mapping module regions...
 Mapping PEB regions...
 Mapping TEB and stack regions...
 Mapping heap regions...
 Mapping page heap regions...
 Mapping other regions...
 Mapping stack trace database regions...
 Mapping activation context regions...
    
 Usage:                  <unknown>
 Base Address:           00000202`27690000
 End Address:            00000202`2769f000
 Region Size:            00000000`0000f000 (  60.000 kB)
 State:                  00001000          MEM_COMMIT
 Protect:                00000004          PAGE_READWRITE
 Type:                   00020000          MEM_PRIVATE
 Allocation Base:        00000202`27690000
 Allocation Protect:     00000004          PAGE_READWRITE

释放后的内存页信息：

 0:000> !address 20227690810
    
                                         
 Mapping file section regions...
 Mapping module regions...
 Mapping PEB regions...
 Mapping TEB and stack regions...
 Mapping heap regions...
 Mapping page heap regions...
 Mapping other regions...
 Mapping stack trace database regions...
 Mapping activation context regions...
    
 Usage:                  Free
 Base Address:           00000202`27661000
 End Address:            00000202`276a0000
 Region Size:            00000000`0003f000 ( 252.000 kB)
 State:                  00010000          MEM_FREE
 Protect:                00000001          PAGE_NOACCESS
 Type:                   <info not present at the target>

第五次尝试：监控 Win32 系统内部 API NtFreeVirtualMemory 的调用；每次命中时打印其参数（Base Address、大小等）。

该函数在 x64 下的调用约定为：

 NtFreeVirtualMemory(
     HANDLE  ProcessHandle,  // rcx
     PVOID*  BaseAddress,    // rdx
     PSIZE_T RegionSize,     // r8
     ULONG   FreeType        // r9
 );

设置一个打印型断点：

 bp ntdll!NtFreeVirtualMemory ".if ((@r9d & 0x8000) != 0) {.printf \"MEM_RELEASE: Base=%p Size=%p Ret=%p\n\", poi(@rdx), poi(@r8), poi(@rsp); kb; gc; } .else { gc }"

拿到指针的值后，用 !address 得到对应的 Base Address，然后退出程序（此时会触发 crash）。观察 Command 面板输出，发现这块内存在退出阶段确实被抢先一步释放了：

 MEM_RELEASE: Base=00000223f6b90000 Size=0000000000000000 Ret=00007ffadb260b5f  # RetAddr               : Args to Child                                                           : Call Site
 00 00007ffa`db260b5f     : 00000223`f1080000 00000000`00000000 00000000`00000000 00000223`f1082480 : ntdll!NtFreeVirtualMemory
 01 00007ffa`db26062a     : 00000223`f6b90000 000000be`c394f958 00000000`7ffe0388 00000223`f1080000 : ntdll!RtlpSecMemFreeVirtualMemory+0x2f
 02 00007ffa`db2602e1     : 00000000`00000000 00000223`f6b90000 00000223`f6b90000 00000223`f1080110 : ntdll!RtlpDestroyHeapSegment+0x5e
 03 00007ffa`d8b09f5b     : 00000000`00000000 00000000`00000000 00000000`000c3000 00000223`f88f0000 : ntdll!RtlDestroyHeap+0x101
 04 00007ffa`ae298d17     : 00000000`00000000 00000000`000003b0 00000000`00000000 00000000`00000000 : KERNELBASE!HeapDestroy+0xb
 05 00007ffa`ae2780bb     : 00000000`00000000 000000be`c394fab9 00000000`00000000 00000000`00000000 : gdiplus!InternalGdiplusShutdown+0x60f
 06 00007ff6`9f9e3e5f     : 00000223`f0e8c630 00000000`00000000 00007ff6`9fa0db58 00000000`06cf0000 : gdiplus!GdiplusShutdown+0x9b
 07 00007ff6`9fa07be2     : 00000000`0000000a 00000000`00000000 00000000`00000000 00000000`00000000 : DuilibDemo!wWinMain+0x243 [D:\zoom-src-billable-hours-6x\win-common\test\DuilibDemo\DuilibDemo.cpp @ 126] 
 08 (Inline Function)     : --------`-------- --------`-------- --------`-------- --------`-------- : DuilibDemo!invoke_main+0x21 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 118] 
 09 00007ffa`d987e957     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : DuilibDemo!__scrt_common_main_seh+0x106 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
 0a 00007ffa`db2a7c1c     : 00000000`00000000 00000000`00000000 000004f0`fffffb30 000004d0`fffffb30 : KERNEL32!BaseThreadInitThunk+0x17
 0b 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x2c

也就是说，GDI+ 的 GdiplusShutdown 会释放其申请的堆内存。此时单例持有的 Bitmap指针所指向的内存区域已经失效，随后再执行 delete 就会触发二次释放，最终导致 crash。

总结

程序退出阶段的内存释放操作一定要谨慎，尤其是在持有第三方模块对象指针时：其 new/delete operator 可能被重载。
如果确实需要持有第三方模块的对象指针，在卸载该模块时务必确认是否还有其他地方持有该模块的对象，尤其要关注对象的内存管理是否（不经意地）被该模块接管。
Gdi+ 对象涉及的动态内存由其自行管理，delete 时要特别谨慎，尤其不要在 Gdi+ 模块释放后再 delete 相关对象。因为模块释放时会在内部将其申请的堆内存统一清理掉。

案例代码

由于涉及公司内部代码，这里提供一份同样能够触发 crash 的示例代码（需要事先在 Visual Studio 里创建一个 Windows Desktop Application 项目），程序退出时必然崩溃：

/// vvv
#include <objbase.h>
#define GDIPVER 0x0110
#include <gdiplus.h>
#pragma comment(lib, "gdiplus.lib")
/// ^^^

#include "framework.h"
#include "WindowsProject1.h"

/// vvv
class BitmapOwner {
public:
  BitmapOwner() : bitmap_(new Gdiplus::Bitmap(1, 1)) {}
  ~BitmapOwner() { delete bitmap_; }
private:
  Gdiplus::Bitmap* bitmap_;
};

BitmapOwner& GetBitmapOwner() {
  static BitmapOwner instance;
  return instance;
}
/// ^^^

#define MAX_LOADSTRING 100

// Global Variables:
HINSTANCE hInst;                                // current instance
WCHAR szTitle[MAX_LOADSTRING];                  // The title bar text
WCHAR szWindowClass[MAX_LOADSTRING];            // the main window class name

// Forward declarations of functions included in this code module:
ATOM                MyRegisterClass(HINSTANCE hInstance);
BOOL                InitInstance(HINSTANCE, int);
LRESULT CALLBACK    WndProc(HWND, UINT, WPARAM, LPARAM);
INT_PTR CALLBACK    About(HWND, UINT, WPARAM, LPARAM);

int APIENTRY wWinMain(_In_ HINSTANCE hInstance,
                     _In_opt_ HINSTANCE hPrevInstance,
                     _In_ LPWSTR    lpCmdLine,
                     _In_ int       nCmdShow)
{
    UNREFERENCED_PARAMETER(hPrevInstance);
    UNREFERENCED_PARAMETER(lpCmdLine);
		
		// vvv
    ::CoInitialize(NULL);
    ULONG_PTR gdiToken = NULL;
    Gdiplus::GdiplusStartupInput gdiSI;
    Gdiplus::GdiplusStartup(&gdiToken, &gdiSI, NULL);

    GetBitmapOwner();  // will initialize a singleton
		/// ^^^
		
    // Initialize global strings
    LoadStringW(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING);
    LoadStringW(hInstance, IDC_WINDOWSPROJECT1, szWindowClass, MAX_LOADSTRING);
    MyRegisterClass(hInstance);

    // Perform application initialization:
    if (!InitInstance (hInstance, nCmdShow))
    {
        return FALSE;
    }

    HACCEL hAccelTable = LoadAccelerators(hInstance, MAKEINTRESOURCE(IDC_WINDOWSPROJECT1));

    MSG msg;

    // Main message loop:
    while (GetMessage(&msg, nullptr, 0, 0))
    {
        if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }
    }
		
		/// vvv
    Gdiplus::GdiplusShutdown(gdiToken);
    ::CoUninitialize();
    /// ^^^

    return (int) msg.wParam;
}

ATOM MyRegisterClass(HINSTANCE hInstance)
{
    WNDCLASSEXW wcex;

    wcex.cbSize = sizeof(WNDCLASSEX);

    wcex.style          = CS_HREDRAW | CS_VREDRAW;
    wcex.lpfnWndProc    = WndProc;
    wcex.cbClsExtra     = 0;
    wcex.cbWndExtra     = 0;
    wcex.hInstance      = hInstance;
    wcex.hIcon          = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_WINDOWSPROJECT1));
    wcex.hCursor        = LoadCursor(nullptr, IDC_ARROW);
    wcex.hbrBackground  = (HBRUSH)(COLOR_WINDOW+1);
    wcex.lpszMenuName   = MAKEINTRESOURCEW(IDC_WINDOWSPROJECT1);
    wcex.lpszClassName  = szWindowClass;
    wcex.hIconSm        = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_SMALL));

    return RegisterClassExW(&wcex);
}

BOOL InitInstance(HINSTANCE hInstance, int nCmdShow)
{
   hInst = hInstance; // Store instance handle in our global variable

   HWND hWnd = CreateWindowW(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,
      CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, nullptr, nullptr, hInstance, nullptr);

   if (!hWnd)
   {
      return FALSE;
   }

   ShowWindow(hWnd, nCmdShow);
   UpdateWindow(hWnd);

   return TRUE;
}

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)
    {
    case WM_COMMAND:
        {
            int wmId = LOWORD(wParam);
            // Parse the menu selections:
            switch (wmId)
            {
            case IDM_ABOUT:
                DialogBox(hInst, MAKEINTRESOURCE(IDD_ABOUTBOX), hWnd, About);
                break;
            case IDM_EXIT:
                DestroyWindow(hWnd);
                break;
            default:
                return DefWindowProc(hWnd, message, wParam, lParam);
            }
        }
        break;
    case WM_PAINT:
        {
            PAINTSTRUCT ps;
            BeginPaint(hWnd, &ps);
            // TODO: Add any drawing code here...
            EndPaint(hWnd, &ps);
        }
        break;
    case WM_DESTROY:
        PostQuitMessage(0);
        break;
    default:
        return DefWindowProc(hWnd, message, wParam, lParam);
    }
    return 0;
}

INT_PTR CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
    UNREFERENCED_PARAMETER(lParam);
    switch (message)
    {
    case WM_INITDIALOG:
        return (INT_PTR)TRUE;

    case WM_COMMAND:
        if (LOWORD(wParam) == IDOK || LOWORD(wParam) == IDCANCEL)
        {
            EndDialog(hDlg, LOWORD(wParam));
            return (INT_PTR)TRUE;
        }
        break;
    }
    return (INT_PTR)FALSE;
}

在JetBrains IDE中使用Claude Code集成Claude Code的简单做法 —— 以Windows系统为例

Fri, 08 May 2026 00:00:00 +0000

这两年AI的浪潮愈发汹涌，给传统的IDE带来了不少的挑战。一直被诟病落后于AI时代的JetBrains虽然也积极地集成Copilot，推出自家的AI工具（Junie），但还是抵挡不住Cursor、Claude Code的强烈冲击。大家的开发体验从基于IDE的编码，逐步演变成通过CLI的方式进行Vibe Coding。但从我的角度出发，开发始终离不开IDE，代码浏览、跳转、重构、调试、版本管理等能力，仍然是成熟IDE的核心优势。如果能将Claude Code这些AI Agent集成在IDE中，相信还是能做到两全其美的效果。

最近，JetBrains也努力地将ACP继承在自家的产品中，有效地改善了在PyCharm、IntelliJ IDEA等IDE中的Vibe Coding体验。其ACP Registry也提供了多个AI Agent的集成，里面也包含了Claude Agent —— 但是，这个Claude Agent并非用的是我们本地Claude Code的登陆状态或订阅！它实际上消耗的是JetBrains自家AI的Credit，因此不到几次问答后就会触及额度上限。

那么，我们如何将Anthropic订阅的本地Claude Code集成在JetBrains IDE中呢？一个比较简单的做法是使用第三方ACP工具 claude-agent-acp，将Claude Code通过ACP协议接入到JetBrains的AI Chat面板。

环境概述

Windows操作系统（Windows 11）
本地已安装好Claude Code，并且已登录
支持ACP协议的JetBrains IDE，至少需要2025.3.x版本，推荐使用2026.1及以上版本
已安装Node.js及npm

过程概述

打开PowerShell命令行。
键入npm install -g @agentclientprotocol/claude-agent-acp命令，全局安装claude-agent-acp。
安装完毕后，可以先执行claude-agent-acp命令，确认claude-agent-acp是否可以正常运行。

接着执行Get-Command claude-agent-acp，查看claude-agent-acp的完整路径，此时会有类似以下格式的输出，记住Source列里的路径。

 CommandType     Name                                               Version    Source
 -----------     ----                                               -------    ------
 ExternalScript  claude-agent-acp.ps1                                          C:\Users\Jeza\AppData\Roaming\npm\claude-agent-acp.ps1

需要特别注意的是：如果这里得到的是.ps1文件路径，那么在后续JetBrains的ACP配置中，需要将扩展名从 .ps1 改成 .cmd。比如上面的路径C:\Users\Jeza\AppData\Roaming\npm\claude-agent-acp.ps1，在后续的配置中，需要改成C:\Users\Jeza\AppData\Roaming\npm\claude-agent-acp.cmd
打开JetBrains IDE（如PyCharm），在右侧的AI Chat面板上，点击Options - Add Custom Agent，此时IDE会打开一个acp.json配置文件。

在acp.json里的agent_servers中新增一个agent，如：

 {
     "default_mcp_settings":{},
     "agent_servers": {
         "claude-code-acp": {
             "command": "C:\\Users\\Jeza\\AppData\\Roaming\\npm\\claude-agent-acp.cmd"
         }
     }
 }

再次强调，这里的command填写以.cmd结尾的绝对路径，而不是.ps1路径。

按 Ctrl + S保存配置，保存后，回到AI Chat面板查看下方的Agents列表。如果一切正常，里面应该会出现一个名为claude-code-acp的agent。切换到该agent，如果右侧出现类似”Mode: Default”、”Mode: Opus (1M context)”的模型或模式选项，通常说明配置已经基本成功。
最后，尝试在AI Chat中发送一条消息，确认Claude Code是否能够正常响应。

已知问题

目前在JetBrains IDE 2026.1.x版本中，这种方式还不是特别稳定。遇到过AI Chat一直卡在 Working 状态的问题，而且此时无法正常停止，只能通过重启IDE来恢复。

Git连接提示"Connection closed by xxx"的解决方法

Fri, 09 Jan 2026 00:00:00 +0000

今天给自己的Ubuntu系统配置git的时候，发现没法连接Github，clone/fetch/pull此类涉及网络连接的操作都会出错，并提示”Connection closed by 20.205.243.166 port 22”。一开始以为是SSH密钥或者路由器DNS有问题，但重置了一遍后还是报错。经过查阅资料发现，可能是因为网络中的某一环（防火墙/代理服务器）屏蔽掉了22端口导致的。我们可以键入以下命令尝试是否可以通过443端口SSH连接到Github上：

ssh -T -p 443 git@ssh.github.com

如果提示如下信息，说明可以通过443端口连接到Github：

Hi {Your Github Username}! You've successfully authenticated, but GitHub does not provide shell access.

此时我们可以曲线救国，配置git使用443端口进行SSH连接。

具体方法是编辑~/.ssh/config文件（如果没有则新建一个），添加如下内容：

[url "ssh://git@ssh.github.com:443/"]
insteadOf = git@github.com:

上述配置新增一个路径重写（URL Rewriting）规则：每当执行Git操作（如clone、push、pull）且目标地址以“git@github.com:”开头时（通过insteadOf字段指定），Git会自动将其替换为“ssh://git@ssh.github.com:443/”。比如，当你执行命令：

git clone git@github.com:owner/repo.git

Git会转换为：

git clone ssh://git@ssh.github.com:443/owner/repo.git

这样就能通过443端口与Github建立SSH连接，绕过22端口被屏蔽的问题。

参考资料

跨仓库应用Git提交的方法

Wed, 05 Nov 2025 00:00:00 +0000

最近在处理公司项目时，遇到需要将一个Git仓库中的某些提交应用到另一个仓库中的情况。由于是两个分离的仓库，直接使用git cherry-pick命令并不可行。经过一番研究，发现可以通过导出补丁文件并应用到目标仓库来实现这一需求。本文分享具体的操作步骤和注意事项。

太长不看

在源仓库中，使用git format-patch命令将所需要的提交导出成补丁文件。如果需要将多个提交合并成一个补丁文件，可以使用git format-patch -<n> HEAD --stdout > <patch-file>命令。
在目标仓库中，使用git apply或者git am命令将补丁文件应用到目标仓库。如果两个仓库的目录结构不一样，可使用-p<n>选项和--directory选项来调整路径。比如，将仓库A中关于文件src/path/main.cpp的修改应用到仓库B中对应的文件Source/path/main.cpp，可以使用如下命令：

git apply <patch-file> \ 
    -p2 \   # remove 2 leading directory ("a/src/") from the path in the patch
    --directory="Source"  # prepend "Source/" to the path

适用场景

两个仓库A, B中具有相同名字的文件，且文件的内容大致相同，希望能将仓库A中对此文件的修改”cherry-pick”到仓库B中（当然，cherry-pick只能用于同一仓库的不同分支中，并不支持跨仓库提交）
两个仓库具有几乎一致的源码，希望能将仓库A的某个commit应用在仓库B中。这种情况一般发生在工程结构的重构，比如将一个仓库内的某个目录抽出来，单独作为一个新的仓库来维护。但前面的仓库因为某种历史原因，该目录仍未删除，形成了同一份代码（或工程），两个仓库并行维护的状态。因此在开发的过程中，需要往两个仓库提交几乎一致的代码。

具体过程

示例仓库结构

以一个示例仓库为例，我们先用git clone --recursive https://github.com/JezaChen/ApplyPatchAcrossRepoSample将其clone到本地。里面有两个子仓库”repoA”以及”repoB”，其中repoA的目录结构如下：

repoA/
  ├── src/
      └── path
            └── main.cpp

repoB的目录结构如下：

repoB/
  ├── src/
      └── Source
            └── main.cpp

而repoA里面的main.cpp和repoB里面的main.cpp内容大致相同。除了第8行所传入的参数不一样，其他内容是相同的。

输出补丁

我们对repoA的main.cpp进行改动，切去新的分支dev，在第一个提交（da93915）中，将add函数修改成

int add(int a, int b) {
    int sum = a + b;
    std::cout << "The sum is: " << sum << std::endl;
    return sum;
}

然后，在第二个提交（7669cbd）中，给add函数新增一行注释

// This function adds two integers and returns the result
int add(int a, int b) {
    int sum = a + b;
    std::cout << "The sum is: " << sum << std::endl;
    return sum;
}

如果我们想将这两个提交应用到repoB中，要怎么做呢？最直观的想法是使用cherry-pick，但cherry-pick只能用于同一仓库的不同分支中，并不支持跨仓库提交。这时候，git的补丁机制就派上用场了，我们可以将这两个提交导出成补丁文件，然后再将补丁文件应用到repoB中。

使用git format-patch命令导出补丁文件。在dev分支上，使用以下命令导出最近两次的提交：

git format-patch -2 HEAD

不幸的是，执行之后，会发现这个命令生成了两个补丁文件——能否将其合并成一个呢？当然可以！我们可以通过--stdout选项将其打印到终端上，然后重定向一个文件里（在例中，我们命名为my.patch）：

git format-patch -2 HEAD --stdout > my.patch

最后，我们将所输出的my.patch文件移动到repoB里。

应用补丁

补丁有了，怎么应用到目标仓库（repoB）里面呢？我们不难想到git apply命令，但直接应用git apply my.patch命令会报错，毕竟两个仓库的目录结构是有区别的。

还好，Git提供了灵活的选项——我们可以利用-p<n>和--directory来fix上述的问题：

git apply my.patch -p2 --directory="Source"

其中，-p<n>选项用于去掉补丁文件中路径的前n个目录层级，在本例中，补丁文件中的路径是a/src/path/main.cpp（注意补丁文件里面有个a/），我们需要去掉前两个目录层级a/和src/，使其变成path/main.cpp；

而--directory="Source"选项则是告诉git apply命令，将补丁应用到当前目录下的Source目录中。最终，我们应用补丁的路径就是Source/path/main.cpp，正好对应上了repoB中的main.cpp。

命令执行完毕后，我们可以使用git status命令查看repoB的状态，发现main.cpp文件已经被修改了，且改动的内容是一致的！

除了上述的git apply命令外，我们也可以使用git am命令来应用补丁文件，命令如下，可以发现与git apply命令类似：

git am my.patch -p2 --directory="Source"

两者的区别在于，git am应用补丁后会自动帮你提交，甚至能保留源仓库中的提交信息（比如作者、提交时间、提交说明等）；而git apply则只会应用补丁的内容，不会保留原有的提交信息。

contextlib.contextmanager源码分析

Wed, 10 Sep 2025 00:00:00 +0000

之前一直想写contextlib.contextmanager的实现原理，但也一直都没时间，今天看了Real Python关于上下文管理器的文章，打算补一下之前的坑。

预备知识

Python的语法糖很多，而contextlib.contextmanager主要涉及了三个比较常用的语法糖：装饰器、生成器和上下文管理器（with语句）。

装饰器

装饰器本质上原理很简单：它无非就是起到一种“锦上添花”的功能，在原有的函数上补充功能。被包装的函数以参数的形式传入到装饰器。也就是

@decorator
def func(): ...

本质上等价于

func = decorator(func)

生成器

生成器则可以看成能中途停下来（暂停的时候还能通过yield往外部抛出值），等待下一步指令并继续执行（外部可调用send方法传进指令，也可以直接通过next(...)让它继续）的函数。这里不再赘述，直接来个简单的例子：

def gen():
    print("gen(): Start...")
    first_command = yield "First"
    print(f"gen(): {first_command = }")
    second_command = yield "Second"
    print(f"gen(): {second_command = }")


if __name__ == '__main__':
    g = gen()
    print(f"recv1: {next(g)}")
    print(f"recv2: {g.send('Command1')}")
    try:
        print(f"recv3: {g.send('Command2')}")  # This will raise StopIteration
    except StopIteration:
        pass

可以看到，我们首先调用生成器函数gen得到一个生成器迭代器g，然后使用next(g)激活生成器迭代器g（此时会输出"gen(): Start..."），激活后，会返回一个字符串"First"。然后，我们使用g.send('Command1')发送字符串'Command1'到生成器迭代器中，此时生成器迭代器内的first_command = yield "First"收到外部传入的参数并赋值first_command，也就是first_command='Command1'，并继续执行下去。当生成器迭代器到达终点时，其会抛出一个StopIteration异常告知外部已经。

需要注意的是，如果外部不使用send发送参数而是直接调用next，则生成器迭代器内通过yield表达式所收到的值为None。

这里厘清一下生成器相关的术语：

生成器函数（generator function，大多数场合下，生成器（generator）指的是生成器函数）：函数体内包含yield语句的函数，调用它会返回一个生成器迭代器。
生成器迭代器（generator iterator）：生成器函数所创建的对象，其实现了迭代器协议（__iter__和__next__方法），具有send、throw、close等方法。

一般来说，生成器指的是生成器函数，但有时候也会指生成器迭代器，具体要看上下文。

上下文管理器

上下文管理器则是实现了__enter__和__exit__这两个魔术方法的类，使用时，将该类的实例传入到with语句即可。

我们可以简单实现一个上下文管理器，其会在进出上下文的时候输出一些信息，并且捕获with语句体内的ZeroDivisionError异常。

class SimpleCtxManager:
    def __enter__(self):
        print("Entering the context")
        return self

    def __exit__(self, exc_type, exc_value, traceback):
        print("Exiting the context")
        print(f"{exc_type  = }")
        print(f"{exc_value = }")
        print(f"{traceback = }")

        if isinstance(exc_value, ZeroDivisionError):
            print("Handled ZeroDivisionError")
            return True  # Suppress the exception
        return False  # Propagate other exceptions

我们可以写个简单的使用例子：

if __name__ == '__main__':
    with SimpleCtxManager() as s:
        print(f"{s = }")
    print("OK, no exception\n")

    with SimpleCtxManager() as cm:
        1 / 0  # This will raise ZeroDivisionError
    print("Go ahead, no exception propagated\n")

    with SimpleCtxManager() as cm:
        a = []
        a[1] = -1
    print("This line will not be printed due to IndexError")

运行程序，可以看到无论是否有异常，上下文管理器都能执行到__exit__方法，从而确保其所托管的资源能释放。当然，如果异常继续传播，with语句之后的代码也不会执行了（除非遇到finally语句）。

Entering the context
s = 'Hello'
Exiting the context
exc_type  = None
exc_value = None
traceback = None
OK, no exception

Entering the context
Exiting the context
exc_type  = <class 'ZeroDivisionError'>
exc_value = ZeroDivisionError('division by zero')
traceback = <traceback object at 0x000001AA8C7CFA40>
Handled ZeroDivisionError
Go ahead, no exception propagated

Entering the context
Exiting the context
exc_type  = <class 'IndexError'>
exc_value = IndexError('list assignment index out of range')
traceback = <traceback object at 0x000001AA8C7CF9C0>
python-BaseException
Traceback (most recent call last):
  File "C:\Users\Jeza\PyQtEx\test1.py", line 43, in <module>
    a[1] = -1
    ~^^^
IndexError: list assignment index out of range

`contextmanager`的简单用法

主角终于登场，现在我们使用contextlib.contextmanager对上文的上下文管理器类SimpleCtxManager做个等价的改造：

@contextlib.contextmanager
def SimpleCtxManager():
    print("Entering the context")
    try:
        yield
    except Exception as e:
        print(f"exc_type = {type(e)}")
        print(f"exc_value = {e}")
        print(f"traceback = {e.__traceback__}")
        if isinstance(e, ZeroDivisionError):
            print("Handled ZeroDivisionError:", e)
        else:
            raise
    finally:
        print("Exiting the context")

可以看到，contextlib.contextmanager是一个装饰器，其所包装的是一个生成器函数，其中yield语句前面的代码可以看成__enter__的逻辑，而后面的except…finally…语句则可以看成__exit__的逻辑（处理异常/清理资源）。对比发现，使用contextlib.contextmanager 不仅能让代码易读（看起来更流程化），而且不用专门写一个类，仅需一个生成器函数即可做到一样的功能。

`contextmanager`的源码分析

OK，终于讲到contextlib.contextmanager的原理了。我们可以在Python官方标准库中找到contextlib.py的源代码，定位到contextmanager的实现：

def contextmanager(func):
    @wraps(func)
    def helper(*args, **kwds):
        return _GeneratorContextManager(func, args, kwds)
    return helper

由代码看出，contextmanager是一个装饰器，其接受一个函数func作为参数，在闭包helper内用它来继续构造上下文管理器类_GeneratorContextManager的实例并返回。我们将装饰器contextmanager所返回的闭包helper视作为一个上下文管理器工厂（在外部看起来，它其实用法和上下文管理器是一样的），其接受任意的参数，负责在使用处构造出真正的上下文管理器_GeneratorContextManager的实例。

三个基类的分析

我们继续研究_GeneratorContextManager类的实现，首先看看它的基类：

class _GeneratorContextManager(
    _GeneratorContextManagerBase,
    AbstractContextManager,
    ContextDecorator,
):
    ...

可以看到其继承了三个基类，我们首先看第一个基类_GeneratorContextManagerBase的实现，这也是所有基于生成器的上下文管理器的公共基类：

class _GeneratorContextManagerBase:
    """Shared functionality for @contextmanager and @asynccontextmanager."""

    def __init__(self, func, args, kwds):
        self.gen = func(*args, **kwds)
        self.func, self.args, self.kwds = func, args, kwds
        # Issue 19330: ensure context manager instances have good docstrings
        doc = getattr(func, "__doc__", None)
        if doc is None:
            doc = type(self).__doc__
        self.__doc__ = doc
        # Unfortunately, this still doesn't provide good help output when
        # inspecting the created context manager instances, since pydoc
        # currently bypasses the instance docstring and shows the docstring
        # for the class instead.
        # See http://bugs.python.org/issue19404 for more details.

    def _recreate_cm(self):
        # _GCMB instances are one-shot context managers, so the
        # CM must be recreated each time a decorated function is
        # called
        return self.__class__(self.func, self.args, self.kwds)

不难分析，这个基类所实现的逻辑比较简单：保存生成器函数func以及调用func所需的参数args，kwds 、将func的__doc__属性复制到生成器里面去，以及提供一个_recreate_cm方法，以用来重新创建一个新的上下文管理器实例，保证该实例作为装饰器使用时，在每一次函数调用都能秽土重生，重新生成一个全新的实例用来执行上下文——因为生成器迭代器是一次性的，一旦激活并next下去，就没有回头路了。需要回头？只能重来。（让生成器函数再生一个出来）

再次强调下，这里的_recreate_cm方法仅用于该上下文管理器实例作为装饰器使用的场合。其覆写了第三个基类ContextDecorator的同名方法，后面会讲到。

这个上下文管理器的实例如何作为装饰器使用呢？后面第三个基类ContextDecorator的分析会有例子。这两个基类的关系很密切。

OK，我们来看第二个基类AbstractContextManager的实现：

class AbstractContextManager(abc.ABC):

    """An abstract base class for context managers."""

    __class_getitem__ = classmethod(GenericAlias)

    def __enter__(self):
        """Return `self` upon entering the runtime context."""
        return self

    @abc.abstractmethod
    def __exit__(self, exc_type, exc_value, traceback):
        """Raise any exception triggered within the runtime context."""
        return None

    @classmethod
    def __subclasshook__(cls, C):
        if cls is AbstractContextManager:
            return _collections_abc._check_methods(C, "__enter__", "__exit__")
        return NotImplemented

这个没什么好说的，其就是所有上下文管理器的基类。当然，由于Python是鸭子类型语言，并不强制上下文管理器的实现必须继承这个基类，这个基类只是用来加强类型检查，避免__enter__或__exit__方法没有实现（即上述的__subclasshook__所做的）。比如在下面的例子中，我们定义WrongCtxManager类的时候，犯了个很致命的错误——只实现了__enter__却漏了__exit__——还好！由于这个类继承了AbstractContextManager，在实例化的时候Python解释器会“贴心”地抛出异常，告知你没有实现完整的上下文管理协议。

from contextlib import AbstractContextManager

class WrongCtxManager(AbstractContextManager):
    def __enter__(self):
        print("Entering the context")
        return self

cm = WrongCtxManager()  # error!

~~可见当鹅比当鸭好！~~

我们来看第三个基类ContextDecorator：

class ContextDecorator(object):
    "A base class or mixin that enables context managers to work as decorators."

    def _recreate_cm(self):
        """Return a recreated instance of self.

        Allows an otherwise one-shot context manager like
        _GeneratorContextManager to support use as
        a decorator via implicit recreation.

        This is a private interface just for _GeneratorContextManager.
        See issue #11647 for details.
        """
        return self

    def __call__(self, func):
        @wraps(func)
        def inner(*args, **kwds):
            with self._recreate_cm():
                return func(*args, **kwds)
        return inner

这个基类更像是一个mixin，为子类实现了一个__call__魔术方法，使得上下文管理器实例可作为装饰器使用。在被包装函数调用的前后，执行__enter__和__exit__方法。关于_recreate_cm，前面已经提前路透了，这里不再多说了。

以前面的SimpleCtxManager为例，我们为它加上父类ContextDecorator，此时其实例就可以作为装饰器来用了。

from contextlib import ContextDecorator

class SimpleCtxManager(ContextDecorator):  # Inherit from ContextDecorator
    def __enter__(self):
        print("Entering the context")
        return self

    def __exit__(self, exc_type, exc_value, traceback):
        print("Exiting the context")
        print(f"{exc_type  = }")
        print(f"{exc_value = }")
        print(f"{traceback = }")

        if isinstance(exc_value, ZeroDivisionError):
            print("Handled ZeroDivisionError")
            return True  # Suppress the exception
        return False  # Propagate other exceptions

cm = SimpleCtxManager()

@cm  # Use the instance as a decorator
def func():
    print("func...")

func() 

# Outputs:
# Entering the context
# func...
# Exiting the context
# exc_type  = None
# exc_value = None
# traceback = None

回到`contextlib.contextmanager`

好了，分析完三个基类后，我们终于轮到分析主角contextlib.contextmanager了，可以看到，通过继承上述的三个基类后，contextlib.contextmanager只需将精力花在最核心的__enter__和__exit__两个方法：

（为减少篇幅，下面的源码去掉了注释）

class _GeneratorContextManager(
    _GeneratorContextManagerBase,
    AbstractContextManager,
    ContextDecorator,
):
    def __enter__(self):
        del self.args, self.kwds, self.func
        try:
            return next(self.gen)
        except StopIteration:
            raise RuntimeError("generator didn't yield") from None

    def __exit__(self, typ, value, traceback):
        if typ is None:
            try:
                next(self.gen)
            except StopIteration:
                return False
            else:
                try:
                    raise RuntimeError("generator didn't stop")
                finally:
                    self.gen.close()
        else:
            if value is None:
                value = typ()
            try:
                self.gen.throw(typ, value, traceback)
            except StopIteration as exc:
                return exc is not value
            except RuntimeError as exc:
                if exc is value:
                    exc.__traceback__ = traceback
                    return False
                if (
                    isinstance(value, StopIteration)
                    and exc.__cause__ is value
                ):
                    value.__traceback__ = traceback
                    return False
                raise
            except BaseException as exc:
                if exc is not value:
                    raise
                exc.__traceback__ = traceback
                return False
            try:
                raise RuntimeError("generator didn't stop after throw()")
            finally:
                self.gen.close()

可以看到，_GeneratorContextManager是幕后真正起作用的上下文管理器。我们抛开一些细节性的校验逻辑，分析下__enter__的主要思路：使用next(self.gen)激活生成器迭代器（也就是contextmanager包裹的生成器函数所返回的生成器迭代器），使其走到yield语句处停下——这也意味着，yield语句前面所执行的代码拿来充当__enter__的逻辑了！

我们再看__exit__的实现思路，分两种情况：

如果with语句块没有抛出异常：使用next(self.gen)恢复生成器迭代器，并期望它能执行到最后（包括走完finally语句块）。如果发现生成器迭代器暂停了（说明又遇到了yield），则这个生成器函数的实现不符合contextmanager的规范，抛出RuntimeError。
如果with语句块抛出了异常：将异常转发到生成器迭代器的yield 表达式处（self.gen.throw(typ, value, traceback)），给它一个机会做清理或选择抑制异常，然后再根据它所抛出的异常再做处理——
- 如果抛出的是StopIteration且其异常实例不同于所传入的异常实例（确保了这个StopIteration是生成器迭代器自己执行完毕所抛出的，而非重新raise了所传入的异常（尤其这个所传的异常也是StopIteration）），意味着它选择了抑制异常，此时__exit__返回True；
- 如果抛出的是其他异常，则说明生成器选择了不抑制异常，此时__exit__返回False，让异常继续传播。

里面还有一些细节也挺有意思的，这里就先不讲了，有空的话再原地补坑。先这样，睡觉~

穷哥们的电子书及笔记多平台同步免费方案

Sat, 06 Sep 2025 00:00:00 +0000

随着电子书资源如雨后春笋般地涌现在互联网，很多人都从传统的纸质书阅读转移到电子书上。对于一些专业相关的书籍，电子书往往都是PDF格式，且需要做大量的笔记。我们往往希望这些笔记能够多端同步，可随时随地地翻阅以前的读书心得。而目前也有不少的解决方案，比如MarginNote，GoodNotes这些，但这些应用往往需要收费，且可同步的平台往往也受限颇多。对于穷哥们而言，我们需要探索更实惠且更实用的阅读及同步方案，在不花一分钱的前提下，能够白嫖享受同步的便利。

使用Zotero进行笔记管理及多端同步

一般对于苹果全家桶而言，使用PDF Expert，MarginNote这些同步PDF及笔记足矣，但这些App大多并不支持Windows，Linux平台，说不上是一个合适的多端同步方案。还好，在学术圈中，还有一个大名鼎鼎的软件——Zotero。虽说Zotero的使用场合大多都是文献管理，但用在PDF电子书阅读上也足够合适。

Zotero官网地址：https://www.zotero.org/

建议注册一个Zotero账号，方便能同步自己的设置到各端。

使用Chrome内嵌PDF阅读器进行OCR分析

对于一些扫描版的PDF，我们没办法直接选择文本进行高亮。在过去，一般都需要借助一些专业PDF工具进行OCR扫描，这些工具往往需要收费，即便有免费使用往往也会存在额度，对于大部头而言可谓杯水车薪。还好，Chrome从2024年的126版本后，其内嵌PDF阅读器已经支持了免费的本地OCR扫描功能！穷哥们的我们可以利用这个功能，不用一分钱即可轻松给扫描版的PDF文件提取文字。

怎么启用这个功能呢？很简单，直接在Chrome里打开PDF文件即可。如果是扫描版PDF，此时Chrome会自动开启OCR，并在左下方会出现一个“正在从PDF文件中提取文本…”的提示。

Chrome上“正在从PDF文件中提取文本”的提示

耐心等待，直至提示消失，此时我们可以发现所有的页面都可以直接选择文字了。完美！

OCR转换后，所有的页面都可以直接选择文字了

遗憾的是，Chrome并不支持将这些文本保存在原PDF中。我们需要曲线救国，使用打印功能将文本保留下来。注意目标打印机选择“另存为PDF”，别选错成自己现实的打印机了，要不然浪费一堆纸🤪

使用打印功能将文本保留下来

可以发现，这时候“打印”下来的PDF文件是可以选择文本的了，但遗憾的是，“打印”之后，书签内容丢失了😨，我们还需要借助PDF工具，将书签迁移过来。

还好还好，书签导入导出功能在很多PDF编辑器中是免费的（毕竟技术含量不算高，收费就过分了）。我们可以使用福昕PDF编辑器，从原来的扫描版PDF导出书签内容，然后导入到“打印”后的PDF就好啦。

在福昕PDF编辑器导出/导入书签内容

此时，我们再导入到Zotero里面，就可以轻松选择并高亮文本了。

使用Infini Cloud进行WebDAV同步

我们还缺最后一步，也是最关键的一步：PDF及笔记的同步。

如果使用Zotero进行PDF及笔记的同步，一般有两种办法：

使用Zotero官方的云同步服务：小贵，和账号强绑定
使用WebDAV协议同步：自定义空间比较大，需要自己寻找支持WebDAV云盘

对于穷哥们而言，使用第二个方法可以省下不少银子。但国内可选的云盘并不大，大厂的云盘往往不支持WebDAV，而坚果云的价格也略贵。我们可以将目光投在国外的云盘上，看看有没有羊毛可薅。

InfiniCLOUD是一个性价比较高的WebDAV云盘，注册后即可有20G的免费空间，相比坚果云的免费方案要实用不少。虽然体验下来，InfiniCLOUD网页版的速度不敢恭维，但用作Zotero WebDAV同步此类实时性要求不高的场合还是足够的。

InfiniCLOUD地址：https://infini-cloud.net/en/

注册成功后，我们可在My Page页面中，开启Apps Connection

开启Apps Connection

将InfiniCLOUD提供的WebDAV地址、账号及密码填到Zotero的设置里，然后开启Sync功能即可。

Zotero WebDAV设置

Enjoy Reading!

附：再白嫖InfiniCLOUD 5G的免费空间

可以在My Page → Referral Bonus → Enter Friends Referral Code 填我的邀请码，能再白嫖5G的免费空间🤪：K8K8Z

InfiniCLOUD推荐奖励

在PyCharm中调试PyQt6程序报错"This application failed to start because no Qt platform plugin could be initialized."的解决办法

Sun, 31 Aug 2025 00:00:00 +0000

在使用PyCharm开发PyQt6程序的时候，有时候调试会遇上一些比较诡异的问题。比如在macOS上，会出现以下报错：

objc[69622]: Class QDarwinBluetoothPermissionHandler is implemented in both /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PySide6/QtCore.abi3.so (0x1070333f8) and /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PyQt6/QtCore.abi3.so (0x106ac6f08). One of the two will be used. Which one is undefined.
objc[69622]: Class QDarwinCalendarPermissionHandler is implemented in both /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PySide6/QtCore.abi3.so (0x107033470) and /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PyQt6/QtCore.abi3.so (0x106ac6f80). One of the two will be used. Which one is undefined.
objc[69622]: Class QDarwinCameraPermissionHandler is implemented in both /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PySide6/QtCore.abi3.so (0x1070334c0) and /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PyQt6/QtCore.abi3.so (0x106ac6fd0). One of the two will be used. Which one is undefined.
objc[69622]: Class QDarwinContactsPermissionHandler is implemented in both /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PySide6/QtCore.abi3.so (0x107033510) and /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PyQt6/QtCore.abi3.so (0x106ac7020). One of the two will be used. Which one is undefined.
objc[69622]: Class QDarwinMicrophonePermissionHandler is implemented in both /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PySide6/QtCore.abi3.so (0x107033560) and /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PyQt6/QtCore.abi3.so (0x106ac70c0). One of the two will be used. Which one is undefined.
qt.qpa.plugin: Could not load the Qt platform plugin "cocoa" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: offscreen, minimal, cocoa.

同样地，在Windows上可能也会出现类似的问题：

Windows上类似的错误

看起来是缺少插件或者环境问题导致的。但是诡异的是，直接运行却不会出现上述的问题，只有PyCharm上调试才会出现。那这种大概率是PyCharm内部机制影响到运行环境了。

修复方法

如果出现上述问题，可以先使用pip freeze观察下Python环境是否同时安装了PySide6和PyQt6，如果有，那大概率是PyCharm里面的pydevd调试器的补丁代码影响到程序运行了。

打开PyCharm的设置，在Python -> Debugger面板中，如果PyQt compatible已勾选，且所选项为Auto，此时需要调整为程序所用的框架，即PyQt6。保存设置后，重新调试就好啦。

调整PyCharm里的PyQt compatible设置

为什么会这样？

或许你会好奇为什么会出现这种情况，且为什么直接运行的时候又不会报错呢？其实这是pydevd对Qt框架注入测试代码的时候（参见文件_pydev_bundle/pydev_monkey_qt），如果上述设置所选的PyQt compatible为auto，那么它会根据自己的优先级寻找当前环境所安装的目标框架（pyside6，pyside2，pyside,pyqt6，pyqt5,pyqt4），而非真正的”auto”（智能识别程序所用的Qt框架）。如果pydevd发现PySide6已安装，此时只会注入PySide6，而不会注入PyQt6的。

而注入的过程本质是通过import语句导入相应的框架，然后再对其内部的对象进行猴子补丁。这就意味着，对于PyQt6程序，它会在PyQt6导入前，先导入了PySide6，相当于

# --> Inserted by pydevd
import PySide6
# ... monkey patching for PySide6
# <-- Inserted Finished

# Here is your code...
import PyQt6
# ... your code

所以也就是为什么macOS里的PyCharm会抱怨Class QDarwinBluetoothPermissionHandler is implemented in both /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PySide6/QtCore.abi3.so (0x1070333f8) and /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PyQt6/QtCore.abi3.so (0x106ac6f08). One of the two will be used. Which one is undefined.了😅。

macOS 15使用brew安装binutils找不到命令(gobjdump, greadelf)的解决办法

Sat, 30 Aug 2025 00:00:00 +0000

最近在看《程序员的自我修养》，想在自己的mac上试验一下ELF文件的解析，找了下教程，使用brew安装了binutils后，直接在命令行输入gobjdump、greadelf还是找不着命令。最后搜了下，发现brew安装的二进制文件放在了/opt/homebrew/opt上了。遂直接添加到环境变量即可。

export PATH=/opt/homebrew/opt/binutils/bin:$PATH

Cursor连接Github Codespaces札记

Sun, 20 Jul 2025 00:00:00 +0000

Cursor可谓是今年AI Agent编程的网红产品了，其本质是在VS Code的基础上新增AI相关的功能。因此，VS Code的特性和大部分插件，它基本也支持。那么，按理说它也同样支持连接到Github Codespaces上进行开发，再加上强大的AI Agent，岂不美滋滋呢！

可惜的是，由于某种限制，Cursor官方并不能直接连接Github Codespaces。即便通过导入的方法安装VS Code的Github Codespaces扩展，尝试了下，也只能登录和查看Codespaces列表，但无法连接到Codespaces上进行代码编辑。只能换别的路子尝试下。

经过周末的一番尝试，终于通过SSH扩展以及Github CLI成功连接上Github Codespaces了，在codespace上使用AI和在本地代码开发一样丝滑，下面简单分享一下搭建的过程。

前提条件

Cursor扩展：Remote - SSH
需要安装好Github命令行工具Github CLI (gh)，然后根据官方指引登录Github和授权访问codespaces上的内容。

配置过程

先启动需要连接的codespace（可以在Github网页上启动；也可以使用Github CLI键入gh codespace ssh，根据交互式提示连接到codespace上启动，SSH连接成功后键入exit退出即可），然后输入命令gh codespace ssh --config生成SSH配置，不处于运行状态的codespace将被跳过（此时会输出”skiping unavaliable codespace xxx”）。如果观察到该命令有有效的输出（开头是Host xxxx），则说明配置生成成功了。

gh codespace ssh --config输出截图
回去Cursor，键入F1拉起命令面板，输入”SSH”，进入”Remote SSH - Open SSH Configuration File…”，打开SSH配置文件。
将第一步gh codespace ssh --config的输出（如果出现”skiping unavaliable codespace”开头的行，不要将这些行复制过去）添加到配置文件中（在后面追加，不要覆盖原来的内容）。

将gh codespace ssh --config的输出复制到SSH配置文件中
保存后，键入F1拉起命令面板，同样输入”SSH”，进入”Remote SSH - Connect to Host…”连接刚刚配置好的Host。

在命令面板输入SSH，进入”Remote SSH - Connect to Host…”

找到刚刚配置好的Host进行连接
大功告成，此时在新拉起的Cursor界面上点击”Open Folder”即可，一般而言项目目录在”/workspaces/"，Let’s use cursor to code!

在新拉起的Cursor界面上点击”Open Folder”，打开项目所在目录

C++模板元编程学习笔记 1: 模板的模板参数

Wed, 16 Jul 2025 00:00:00 +0000

模板的模板参数是C++模板元编程一个重要的基础概念。它允许我们在模板中使用其他模板作为参数，从而实现更复杂的类型和行为。

首先看一段简单的代码示例：

#include <iostream>
#include <tuple>

using namespace std;

template<typename>
struct first_type_getter {};

template<template<typename...> typename Ts, typename T1, typename... TN>
struct first_type_getter<Ts<T1, TN...>> {
    using type = T1;
};

// 不能这样子写
// 这样的话，first_type需要提供不止一个模板参数的
// 原本的 first_type<tuple<int, float, double>> 就要变成 first_type<tuple, int, float, double>
// template<template<typename...> typename Ts, typename T1, typename... TN>
// using first_type = typename first_type_getter<Ts<T1, TN...>>::type;

template<typename T>
using first_type = typename first_type_getter<T>::type;

int main(){
    cout << is_same_v<first_type<tuple<int, float, double>>, int> << endl;  // 1
    cout << is_same_v<first_type<tuple<int, float, double>>, float> << endl;  // 0
    cout << is_same_v<first_type<tuple<int, float, double>>, long> << endl; // 0
}

在这里，我们首先定义了一个通用的模板 first_type_getter，它接受一个类型参数。然后，我们对这个模板进行了偏特化，通过模板的模板参数使其能够深入获取参数内部的类型。这个偏特化版本提取了模板参数Ts中的第一个类型 T1，并将其定义为 type。在后续使用时，我们就可以通过first_type<std::tuple<int, float, double>>来获取元组的第一个类型int。

模板的模板参数语法

需要注意的是，使用模板的模板参数时，正确的语法应该长这样 template<template<typename...> typename Ts>。其中template<typename...>表示这个参数是一个模板，然后后面还需要加上typename以表明这是一个类型参数。

在上述的例子中，即便Ts的实参是一个类型别名，编译器仍然能够正确解析。

比如，如果我们使用using MyTuple = std::tuple<int, float, double>;，然后调用 first_type<MyTuple>，编译器仍然能够正确解析出 int 作为第一个类型。

为什么这里需要以偏特化的方式来实现第一个类型获取？

我们先假定不用偏特化的形式，直接定义一个模板：

template<template<typename...> typename Ts, typename T1, typename... TN>
struct first_type_getter {
    using type = T1;
};

如此，我们可以使用first_type_getter<std::tuple<int, float, double>>来获取第一个类型吗？答案是否定的。因为在这种情况下，first_type_getter的实例化需要提供不止一个模板参数（因为形参列表有多个参数），和我们的本意相悖。由于我们只需要传一个模板实参，且目的是从该模板实参中提取出内部的参数，所以只能先定义一个通用的、接受一个类型参数的模板，然后再对其进行偏特化。