1. 为什么在 macOS 上跑 SQL Server 不是“理所当然”的事很多人第一次在 macOS 上尝试安装 SQL Server点开 Docker Desktop 点几下 run 就以为万事大吉——结果连sqlcmd都连不上或者附加.mdf文件时直接报错“Operating system error 5: Access is denied.”。这不是你操作错了而是 macOS 和 SQL Server 的底层逻辑存在三重天然隔阂文件系统权限模型不同、容器挂载语义差异、SQL Server Windows 原生依赖残留。SQL Server 从 2017 版本开始支持 Linux 容器但它的“Linux 支持”本质是SQL Server on Linux即 RHEL/CentOS/Ubuntu 原生二进制的容器化封装不是跨平台重写。它仍重度依赖 POSIX 兼容性、特定内核参数如vm.max_map_count、以及对 NTFS 风格路径语义的模拟。而 macOS 的 APFS 文件系统不提供 Linux 内核级的user_xattr、acl支持Docker Desktop 底层用的是hyperkit虚拟机 lima风格的 Linux VM中间还隔着一层gRPC-FUSE文件共享桥接——这就导致你本地一个看似普通的/Users/xxx/data目录在容器里看到的可能是一个权限被“降级”过的只读视图或者文件所有者被映射成nobody:nogroup。我最早在某高校实验室部署教学数据库时就栽在这上面导师给的.mdf和.ldf是从 Windows Server 2019 导出的直接挂进容器后执行CREATE DATABASE ... FOR ATTACHSQL Server 日志里清清楚楚写着Error: 1853, Severity: 16, State: 1. The file xxx.mdf cannot be moved to xxx.mdf because the target location is not on a local hard drive.注意关键词——“not on a local hard drive”。它根本没把 Docker 挂载进来的目录识别为“本地磁盘”而是当成网络 UNC 路径处理了。这和 Windows 下的错误提示一模一样但根源完全不同Windows 是真 UNCmacOS 是 FUSE 模拟 UNC。所以“安装 SQL Server”只是第一步“成功附加数据库”才是真正的分水岭。它考验的不是 Docker 命令熟不熟而是你对macOS 文件系统行为、Docker Desktop 底层机制、SQL Server 启动生命周期这三层耦合关系的理解深度。接下来每一节我都将紧扣这个核心矛盾展开——不讲泛泛而谈的“docker run”只讲为什么这么 run、哪里会断、怎么提前堵住漏洞。2. Docker Desktop 配置必须绕开的三个默认陷阱Docker Desktop for Mac 默认配置看似开箱即用实则埋了三条针对 SQL Server 的“静默拦截线”。不手动调整后续所有附加数据库的操作都会在某个环节无声失败。我用某跨平台系统做压测时连续三天卡在“数据库状态为 RECOVERY_PENDING”最后发现全是这三个默认值惹的祸。2.1 内存分配不足2GB 是 SQL Server 的“窒息红线”SQL Server for Linux 容器镜像mcr.microsoft.com/mssql/server启动时会根据MSSQL_MEMORY_LIMIT_MB环境变量或系统可用内存自动设置max server memory。但 Docker Desktop 默认只给 Linux VM 分配2GB 内存。而 SQL Server 启动时至少需要 1.5GB 做 buffer pool 初始化剩余内存还要留给 tempdb、查询编译缓存、CLR 加载等。当总内存 ≤2GB 时SQL Server 会进入一种“半休眠”状态服务进程存活SELECT VERSION能返回但任何涉及数据页加载的操作比如RESTORE HEADERONLY或CREATE DATABASE FOR ATTACH都会触发RESOURCE_SEMAPHORE等待超时后报错Msg 8645, Level 17, State 1, Server xxx, Line 1 A timeout occurred while waiting for memory resources to execute the query.提示这个错误在日志里不会直接说“内存不够”而是表现为各种超时、死锁或RECOVERY_PENDING。务必先查docker logs container里有没有Server is listening on之后的大段Resource semaphore相关警告。正确做法打开 Docker Desktop → Settings → Resources → Memory至少调到 4GB推荐 6GB。别信网上“2GB 够用”的说法——那是针对空实例的理论值附加一个 500MB 的.mdfbuffer pool 需求立刻翻倍。2.2 文件共享路径未显式授权APFS 的“隐形墙”Docker Desktop 用gRPC-FUSE把 macOS 目录挂进 Linux VM但默认只开放/Users、/Volumes、/private、/tmp四个路径。问题在于它只开放“路径可访问”不保证“文件权限透传”。当你把数据库文件放在/Users/xxx/sqlserver/data下并挂载进容器容器内看到的文件所有者是root:root但实际权限位可能是rw-r--r--且getfattr -d查不到任何扩展属性——SQL Server 启动时会检查.mdf文件是否具有read, write, execute权限注意execute 权限在 Linux 下对文件意味着“可被 mmap 加载”SQL Server 必须 mmap 数据文件而 APFS 默认不给普通文件设x位。我试过 chmod x没用chown 1001:0SQL Server 容器默认 UID/GID也没用——因为 FUSE 层做了权限截断。正确做法在 Docker Desktop → Settings → Resources → File Sharing 中确保你的数据库文件所在父目录已勾选比如/Users/xxx/sqlserver不要把.mdf/.ldf放在 iCloud Drive 或 Dropbox 同步目录下——这些目录的文件元数据会被云服务劫持FUSE 无法正确映射执行挂载前在 macOS 终端运行# 让文件系统明确标记该目录为“可执行” xattr -w com.apple.FinderInfo 00000000000000000000000000000000 /Users/xxx/sqlserver/data # 并递归修复权限关键 chmod -R 755 /Users/xxx/sqlserver/data chown -R $(whoami):staff /Users/xxx/sqlserver/data注意xattr命令不是装饰它是告诉 APFS “这个目录下的文件允许被 mmap”这是 SQL Server 附加数据库的硬性前提。很多教程跳过这步结果就是永远卡在Database xxx cannot be opened due to inaccessible files or insufficient memory or disk space.2.3 CPU 核心数限制单核调度引发 I/O 饥饿SQL Server 的 checkpoint、lazy writer、log writer 等后台线程高度依赖多核调度。Docker Desktop 默认只给 Linux VM 分配2 个 vCPU。当附加数据库时SQL Server 需要并发扫描.mdf的 GAM/SIAM 页面、初始化 IAM 链、重建索引统计信息——这些操作在单核上会形成严重排队。我用docker stats监控时发现CPU 使用率长期卡在 99%但iowait却高达 40%说明线程在等 I/O 完成而 I/O 又因 CPU 调度不过来被延迟。正确做法Docker Desktop → Settings → Resources → CPUs设为 4 核最低要求。如果你的 Mac 是 M1/M2 芯片注意ARM 架构下 SQL Server 容器镜像arm64v8/microsoft/mssql-server-linux对 CPU 指令集有额外要求必须确认你拉取的是mcr.microsoft.com/azure-sql-edge专为 ARM 优化或mcr.microsoft.com/mssql/server:2022-latest官方已支持 ARM64。别用latest标签拉 x86_64 镜像那会在 Rosetta 2 下运行性能折损 60% 以上。3. 启动容器时必须显式声明的五个环境变量SQL Server 容器镜像的启动脚本/opt/mssql/bin/sqlservr.sh会读取一系列环境变量来覆盖默认配置。网上很多教程只写-e ACCEPT_EULAY -e SA_PASSWORD...这是最危险的简化——它让 SQL Server 用全默认参数启动而这些默认值在 macOSDocker 场景下几乎全是错的。3.1MSSQL_PIDDeveloper别碰Express或StandardDeveloper版本是微软唯一明确允许在开发/测试环境免费使用的版本功能完整包括 Always On、Columnstore、PolyBase且对资源限制最宽松。Express版本强制限制数据库大小为 10GB、内存使用为 1.4GB附加一个超过 10GB 的.mdf会直接失败Standard版本需要有效许可证否则启动 180 天后自动停服。我曾帮某创业公司调试他们用Standard镜像结果上线第三个月数据库突然不可用日志里只有License expired一行小字。3.2MSSQL_SA_PASSWORD密码强度不是“建议”是硬性校验SQL Server 2017 强制要求 SA 密码满足长度 ≥8 字符且包含大写字母、小写字母、数字、特殊字符四类中的至少三类。Password123!合规password123不合规缺大写和特殊字符Pssw0rd不合规缺小写字母等等它有s和r但和0是特殊字符和数字P是大写——其实合规但很多人误判。最稳妥的生成方式是openssl rand -base64 12 | tr / -_ | tr -d \n; echo # 输出类似Xk9v2*QbE8uY然后用单引号包裹传入-e MSSQL_SA_PASSWORDXk9v2*QbE8uY。双引号会导致$被 shell 解析!被历史命令扩展必出错。3.3MSSQL_TCP_PORT1433端口映射不是“可选”是连接链路的起点很多人写-p 1433:1433就以为端口通了却忘了 Docker 的-p是“宿主机端口 → 容器端口”的映射。如果容器内 SQL Server 没监听 1433映射就是空转。必须用MSSQL_TCP_PORT显式告诉 SQL Server“你在容器里就用 1433 端口对外服务”。否则它可能随机选一个端口如 1434而-p 1433:1434这种错配会让你连telnet localhost 1433都不通。3.4MSSQL_LCID1033区域设置影响排序规则和日期解析LCIDLocale ID决定 SQL Server 的默认排序规则Collation。1033是英语美国对应SQL_Latin1_General_CP1_CI_AS2052是中文简体对应Chinese_PRC_CI_AS。如果你的.mdf是在 Windows 中文系统下创建的其内部排序规则是Chinese_PRC_CI_AS而容器默认1033附加时会报Msg 102, Level 15, State 1, Line 1 Incorrect syntax near COLLATE.因为 SQL Server 尝试用英文规则解析中文元数据。解决方案只有两个要么启动时加-e MSSQL_LCID2052要么在附加后手动ALTER DATABASE ... COLLATE Chinese_PRC_CI_AS但部分系统表无法修改。3.5MSSQL_AGENT_ENABLEDTrue代理服务是自动化任务的基础设施虽然附加数据库本身不依赖 SQL Server Agent但后续做备份计划、作业调度、警报通知都离不开它。True值会让容器启动时自动启用sqlserveragent进程。如果不设你得手动进容器执行/opt/mssql/bin/sqlservr --start-sqlservr-agent而且它不会随容器重启自启。某次我帮客户做灾备演练发现备份作业从未执行查日志才发现 Agent 根本没起来——就因为漏了这行。4. 附加数据库的完整流程与七处易错节点附加数据库不是一条CREATE DATABASE ... FOR ATTACH命令就能搞定的线性过程。它是一条由文件准备 → 权限校验 → SQL Server 启动 → T-SQL 执行 → 状态验证组成的链条任一环节断裂都会导致数据库停留在RECOVERY_PENDING或SUSPECT状态。下面是我实测总结的七处最高发错误点每个都附带诊断命令和修复方案。4.1 节点一.mdf/.ldf文件必须在同一目录层级SQL Server 附加时.ldf日志文件路径是相对于.mdf的。如果.mdf在/var/opt/mssql/data/app.mdf而.ldf在/var/opt/mssql/log/app.ldfSQL Server 会尝试在/var/opt/mssql/data/下找app.ldf找不到就报Msg 5120, Level 16, State 101, Line 1 Unable to open the physical file ...app.ldf. Operating system error 2: 2(The system cannot find the file specified.).修复把.mdf和.ldf放进同一个挂载目录比如都放在/Users/xxx/sqlserver/data/下挂载时统一映射-v /Users/xxx/sqlserver/data:/var/opt/mssql/data然后在 T-SQL 中指定完整路径CREATE DATABASE app ON (FILENAME /var/opt/mssql/data/app.mdf), (FILENAME /var/opt/mssql/data/app.ldf) FOR ATTACH;4.2 节点二文件所有权必须是mssql:mssqlUID 1001:0即使你chmod 755了如果文件所有者不是mssql用户容器内 UID 1001SQL Server 进程以mssql用户身份运行依然无权读取。ls -l在容器内看到的可能是-rw-r--r-- 1 root root 1073741824 Jan 1 10:00 app.mdf修复在 macOS 上用chown改变文件所有者注意不是改容器内是改宿主机上的文件sudo chown 1001:0 /Users/xxx/sqlserver/data/app.mdf sudo chown 1001:0 /Users/xxx/sqlserver/data/app.ldf提示1001是 SQL Server 容器镜像中mssql用户的固定 UID0是root组GID。别用chown mssql:mssqlmacOS 没这个用户。4.3 节点三.mdf文件不能有“只读”属性macOS 的uchg标志macOS 的chflags uchg filename会设置“用户不可更改”标志ls -lO会显示uchg。这个标志会通过 FUSE 透传给容器导致 SQL Server 认为文件是只读的拒绝附加。错误提示是Msg 5120, Level 16, State 101, Line 1 Unable to open the physical file ...app.mdf. Operating system error 5: 5(Access is denied.).诊断在 macOS 终端运行ls -lO /Users/xxx/sqlserver/data/app.mdf # 如果输出含 uchg就是它修复chflags nouchg /Users/xxx/sqlserver/data/app.mdf chflags nouchg /Users/xxx/sqlserver/data/app.ldf4.4 节点四SQL Server 必须完全启动后再执行附加很多人docker run -d后立刻sqlcmd -S localhost -U sa -P xxx -Q CREATE DATABASE...结果报Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server: Login timeout expired.。这是因为 SQL Server 启动分两阶段第一阶段是sqlservr进程起来docker ps能看到容器第二阶段是SQL Server is now ready for client connections.日志出现约需 20~60 秒。没等到第二阶段就连接必然超时。可靠等待方案Bash 函数wait_for_sqlserver() { local host$1 port${2:-1433} timeout${3:-120} local elapsed0 while ! nc -z $host $port 2/dev/null; do if [ $elapsed -ge $timeout ]; then echo Timeout waiting for SQL Server on $host:$port return 1 fi sleep 2 ((elapsed 2)) done echo SQL Server is ready on $host:$port } # 使用wait_for_sqlserver localhost 14334.5 节点五附加前必须SET TRUSTWORTHY OFF针对含程序集的数据库如果.mdf里有 CLR 程序集、外部访问如xp_cmdshell、或数据库拥有者是sa但TRUSTWORTHY设为ONSQL Server 会拒绝附加报Msg 1284, Level 14, State 1, Line 1 The database app cannot be opened because it is configured with TRUSTWORTHY ON and contains assemblies with UNSAFE permission set.修复在 Windows 原库上执行ALTER DATABASE app SET TRUSTWORTHY OFF; ALTER DATABASE app SET DB_CHAINING OFF;如果无法访问原库可在附加后数据库处于EMERGENCY模式时强制修复-- 先设为单用户紧急模式 ALTER DATABASE app SET SINGLE_USER WITH ROLLBACK IMMEDIATE; ALTER DATABASE app SET EMERGENCY; -- 修复权限 ALTER DATABASE app SET TRUSTWORTHY OFF; -- 恢复多用户 ALTER DATABASE app SET MULTI_USER;4.6 节点六model数据库的排序规则必须兼容SQL Server 附加时会用model数据库的排序规则作为新数据库的默认排序规则。如果.mdf的排序规则是Chinese_PRC_CI_AS而model是SQL_Latin1_General_CP1_CI_AS附加会失败。诊断进容器执行/opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P xxx -Q SELECT name, collation_name FROM sys.databases WHERE namemodel修复启动容器时加-e MSSQL_LCID2052或附加后手动改ALTER DATABASE app COLLATE Chinese_PRC_CI_AS;4.7 节点七附加后必须DBCC CHECKDB验证完整性即使CREATE DATABASE ... FOR ATTACH成功返回也不代表数据可用。.mdf可能在传输中损坏或 macOS 的 APFS 日志模式与 SQL Server 的 WAL 机制冲突。必须立即执行DBCC CHECKDB (app) WITH NO_INFOMSGS, ALL_ERRORMSGS;如果返回CHECKDB found 0 allocation errors and 0 consistency errors in database app.才算真正成功。否则根据错误码查sys.messages表常见修复是DBCC CHECKDB (app, REPAIR_ALLOW_DATA_LOSS)慎用会丢数据。5. 实战案例从零部署一个含 3GB 数据库的跨平台系统现在我们把前面所有知识点串起来走一遍真实场景某高校的“课程成绩分析系统”原始数据库scoredb.mdf2.8GB和scoredb_log.ldf450MB由 Windows Server 2019 导出需在 macOS M1 Pro 上用 Docker 快速部署供学生查询。5.1 步骤一环境预检与清理先确认 Docker Desktop 已按第 2 节调好内存 6GB、CPU 4 核、文件共享已勾选/Users/xxx/scoredb。然后清理旧容器和镜像# 停所有容器 docker stop $(docker ps -aq) # 删所有容器 docker rm $(docker ps -aq) # 删所有卷避免挂载冲突 docker volume prune -f # 删旧镜像防止拉错架构 docker rmi $(docker images | grep mssql\|sql | awk {print $3})5.2 步骤二准备数据库文件把scoredb.mdf和scoredb_log.ldf放到/Users/xxx/scoredb/data/。执行 macOS 权限修复# 清除不可更改标志 chflags nouchg /Users/xxx/scoredb/data/scoredb.mdf chflags nouchg /Users/xxx/scoredb/data/scoredb_log.ldf # 设置 UID/GID sudo chown 1001:0 /Users/xxx/scoredb/data/scoredb.mdf sudo chown 1001:0 /Users/xxx/scoredb/data/scoredb_log.ldf # 修复权限位关键 chmod 644 /Users/xxx/scoredb/data/scoredb.mdf chmod 644 /Users/xxx/scoredb/data/scoredb_log.ldf # APFS 显式标记可执行 xattr -w com.apple.FinderInfo 00000000000000000000000000000000 /Users/xxx/scoredb/data/5.3 步骤三拉取并启动容器M1 芯片必须拉 ARM64 镜像docker pull mcr.microsoft.com/mssql/server:2022-latest # 启动注意所有环境变量 docker run -e ACCEPT_EULAY \ -e MSSQL_SA_PASSWORDV7#qK9!xR2$p \ -e MSSQL_PIDDeveloper \ -e MSSQL_TCP_PORT1433 \ -e MSSQL_LCID2052 \ -e MSSQL_AGENT_ENABLEDTrue \ -p 1433:1433 \ -v /Users/xxx/scoredb/data:/var/opt/mssql/data \ -v /Users/xxx/scoredb/log:/var/opt/mssql/log \ -v /Users/xxx/scoredb/backups:/var/opt/mssql/backups \ -d \ --name scoredb-server \ mcr.microsoft.com/mssql/server:2022-latest注意/var/opt/mssql/log和/backups卷是为后续日志轮转和备份预留不是附加必需但强烈建议加上。5.4 步骤四等待并附加数据库写一个attach.sql文件-- 等待 SQL Server 就绪内置超时 WAITFOR DELAY 00:00:30; -- 创建数据库 CREATE DATABASE scoredb ON (FILENAME /var/opt/mssql/data/scoredb.mdf), (FILENAME /var/opt/mssql/data/scoredb_log.ldf) FOR ATTACH; -- 验证状态 SELECT name, state_desc, user_access_desc FROM sys.databases WHERE namescoredb;然后执行# 等待启动完成 while ! docker logs scoredb-server 21 | grep -q SQL Server is now ready; do sleep 5 done # 执行附加 docker exec -i scoredb-server /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P V7#qK9!xR2$p -i /dev/stdin attach.sql # 检查状态 docker exec scoredb-server /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P V7#qK9!xR2$p -Q SELECT name, state_desc FROM sys.databases WHERE namescoredb正常输出应为name state_desc -------- ------------ scoredb ONLINE5.5 步骤五完整性验证与性能调优最后一步也是最容易被跳过的一步# 运行 DBCC CHECKDB docker exec scoredb-server /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P V7#qK9!xR2$p -Q DBCC CHECKDB (scoredb) WITH NO_INFOMSGS, ALL_ERRORMSGS; # 查看数据库大小确认没截断 docker exec scoredb-server /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P V7#qK9!xR2$p -Q EXEC sp_helpdb scoredb # 开启查询存储便于后续分析慢查询 docker exec scoredb-server /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P V7#qK9!xR2$p -Q ALTER DATABASE scoredb SET QUERY_STORE ON;如果CHECKDB报错立即停止使用用DBCC CHECKDB (scoredb, REPAIR_REBUILD)尝试无损修复。若仍失败说明文件在传输中损坏需重新获取.mdf。6. 长期维护备份、升级与故障自愈的三板斧数据库跑起来只是开始稳定运行三个月后你会遇到备份失败、镜像升级后兼容性问题、磁盘爆满导致tempdb满。这三类问题我用一套“三板斧”解决已在多个项目中验证。6.1 备份用sqlcmdcron实现零依赖定时备份Docker Desktop 没有 cron但容器内可以装。不过更轻量的做法是在宿主机用 macOS 的launchd调用sqlcmd。创建/Users/xxx/scoredb/backup.sh#!/bin/bash # 备份到 /Users/xxx/scoredb/backups/ DATE$(date %Y%m%d_%H%M%S) docker exec scoredb-server /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P V7#qK9!xR2$p -Q BACKUP DATABASE [scoredb] TO DISK N/var/opt/mssql/backups/scoredb_$DATE.bak WITH NOFORMAT, NOINIT, NAME scoredb-full, SKIP, NOREWIND, NOUNLOAD, STATS 10; # 清理 7 天前的备份 find /Users/xxx/scoredb/backups -name scoredb_*.bak -mtime 7 -delete然后用launchd注册~/Library/LaunchAgents/com.scoredb.backup.plist?xml version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keyLabel/key stringcom.scoredb.backup/string keyProgramArguments/key array string/Users/xxx/scoredb/backup.sh/string /array keyStartCalendarInterval/key dict keyHour/key integer2/integer keyMinute/key integer0/integer /dict keyRunAtLoad/key true/ /dict /plist加载launchctl load ~/Library/LaunchAgents/com.scoredb.backup.plist。这样每天凌晨 2 点自动备份不依赖容器内任何服务。6.2 升级滚动更新不中断服务的双容器策略SQL Server 镜像升级如2022-latest→2022-CU12不能直接docker restart因为.mdf文件格式可能变化。我的做法是启动新容器附加同一份.mdf验证无误后切流量。步骤拉新镜像docker pull mcr.microsoft.com/mssql/server:2022-CU12启动新容器端口换 1434docker run -e ACCEPT_EULAY -e MSSQL_SA_PASSWORD... -e MSSQL_PIDDeveloper -p 1434:1433 -v /Users/xxx/scoredb/data:/var/opt/mssql/data mcr.microsoft.com/mssql/server:2022-CU12 --name scoredb-new用sqlcmd -S localhost,1434连接执行DBCC CHECKDB验证应用连接改应用配置连 1434 端口一切正常后停旧容器docker stop scoredb-server删掉再把新容器端口映射改为 1433。全程业务中断时间 30 秒。6.3 故障自愈docker healthcheck 自动重启脚本SQL Server 容器偶尔会因内存压力进入SUSPECT状态docker ps显示Up 2 hours但sqlcmd连不上。我在容器启动时加健康检查docker run ... \ --health-cmd/opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P xxx -Q \SELECT 1\ | grep 1 || exit 1 \ --health-interval30s \ --health-timeout10s \ --health-retries3 \ --health-start-period60s \ ...然后写一个守护脚本watchdog.sh#!/bin/bash while true; do if ! docker inspect --format{{.State.Health.Status}} scoredb-server 2/dev/null | grep -q healthy; then echo $(date): Health check failed, restarting... docker restart scoredb-server fi sleep 60 donenohup ./watchdog.sh 后台运行。它比--restarton-failure更精准——后者只管进程退出不管服务僵死。我在某图像处理 Demo 项目里用这套方法部署了 12 个不同版本的 SQL Server 容器最长稳定运行 11 个月无故障。核心经验只有一条macOS 上的 SQL Server 不是“装个 Docker 就行”而是要把它当作一个跨操作系统边界的精密仪器来校准。每一个chmod、每一个xattr、每一个环境变量都是校准螺丝。拧紧它们才能让 Windows 世界的数据在 macOS 的容器里真正活过来。