我来帮你拆解下你遇到的这个问题，核心是编译环境不匹配和模块命名冲突，一步步来解决：

1. 工作进程退出错误（C0000005）：编译环境不兼容 #

这个错误是Windows的访问违规，说白了就是你用普通Lua5.1+Luarocks编译的lua-pack.dll，和OpenResty内置的LuaJIT版本不对付：

• OpenResty Windows版用的是定制的LuaJIT，不是标准Lua5.1，扩展必须用OpenResty的工具链编译才能兼容。
• 另外，编译器也有讲究——OpenResty Windows版一般用MinGW编译，如果你用MSVC编译dll，也会出现内存访问错误。

修复步骤：用OpenResty的LuaJIT重新编译 #

1. 先下载带开发工具的OpenResty Windows包（别下只用来运行的精简版）。
2. 打开OpenResty的命令行环境（比如自带的openresty-env.cmd），进入lua-pack源码目录，执行编译命令：

   gcc -O2 -shared -o lua_pack.dll lua-pack.c -I"C:\path\to\openresty\luajit\include" -L"C:\path\to\openresty\luajit\lib" -lluajit-5.1
   

   把路径换成你实际的OpenResty LuaJIT目录就行，编译出来的lua_pack.dll就是适配OpenResty的版本了。

2. 重命名为pack.dll后的加载错误：模块命名冲突 #

你说Windows Luarocks里有pack.lua，这就是问题所在！Lua加载模块时，会优先找.lua文件，再找.dll，所以你把dll改成pack.dll后，require"pack"其实加载的是Luarocks的pack.lua，不是你的扩展。

修复方案二选一： #

• 方案一：保持原模块名：就用编译出来的lua_pack.dll，代码里用require"lua_pack"，和你Linux下的代码保持一致：

  local bpack, bunpack do
      local string_pack = string.pack
      local string_unpack = string.unpack
      require "lua_pack"
      bpack = string.pack
      bunpack = string.unpack
      string.unpack = string_unpack
      string.pack = string_pack
  end
  

• 方案二：调整加载优先级：把你的pack.dll放到单独的目录，然后在Nginx配置里修改加载路径，让dll优先被加载：

  http {
      # 先指定自定义模块目录，让Lua先找这里的dll
      lua_package_cpath "./custom_modules/?.dll;;";
      lua_package_path "./custom_modules/?.lua;;";
      # 其他配置...
  }
  

  把pack.dll放到./custom_modules/下，这样require"pack"就会先加载你的dll了。

3. Linux的so不能在Windows用的原因 #

这个是基础常识啦——Linux的.so是ELF格式的二进制文件，Windows的.dll是PE格式，两者完全不兼容，必须针对各自系统重新编译，不能直接跨平台复制使用。

最后验证 #

编译完适配的lua_pack.dll后，先用OpenResty的resty命令行测试：

resty -e 'require"lua_pack"; print(string.pack("H", 0x1234))'

如果能正常输出二进制数据，说明模块没问题，再放到Nginx配置里运行就不会崩溃了。

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