由于2041Late的iMac 5K，苹果官方最多只支持到macOS 11 Big Sur。所以，我的macOS 12 Monterey和macOS 13 Ventura都是通过OPLP进行安装的。
OCLP是一款第三方的引导程序，它包含引导启动系统和提供部分驱动的功能。
OCLP的5.0正式提供了对于macOS 13 Ventura的支持，所以在升级到新系统之前，我们先升级OCLP到5.0。
重启系统，选择系统的自动更新安装macOS 13 Ventura。
安装完毕重启后，我们发现，原本的屏幕分辨率设置没有了，显示器变成了5K原生的分辨率，字体特别小，而且系统十分卡顿。
这是因为macOS 13 Ventura中移除了对与iMac 5K显卡的驱动支持，此时是没有驱动硬件加速的。
再次打开OCLP，选择"Post Install Root Patch"，然后选择“Install Root Patches”。这会自动下载安装显卡驱动。
按照提示安装完成并重启后，就一切恢复正常了。
当一款应用编码完成、测试通过之后，我们需要将它上架到苹果商店。这时就需要和苹果的审核人员打交道。苹果的审核人员，会从用户和苹果公司等多个角度，对于应用进行审查。他们审查的依据，就是苹果公布的App Store Review Guidelines。但是由于审核人员存在自由裁量权，你经常会遇到不同的审核人员，对于同一件事，出现要求不同的情况。
当审核人员将你的应用拒绝，并且提出拒绝理由之后，你一般有这么几个选项：
上诉曾是一个有力的工具。当你选择上诉后，苹果会打越洋电话过来，听取你的说法。虽然最终结果不见得有利与你。但是在程序上，开发者是感觉受到重视的。
可现如今，上诉往往无法得到电话沟通。甚至很难得到一个确定的结果。苹果将上诉权限交由审核团队自身负责。即负责处理上诉的，就是和你发生理念冲突的审核人员的同事，如果不是他本人的话。我不知道苹果为何这么做，但是这么做本身就是会滋生腐败的。
2002年9月25日，我向往常一样上传了一个macOS版咕唧的新版进行审核。这个新版是为了配合iOS新版发布而进行修改的，改动极小。可以说表面上看不到任何变化。但是就是这个版本，在9月25日上午7点20分被拒绝了。拒绝的理由也是一个全新的理由，说是当用户点击窗口的关闭按钮时，应用没有退出，而是隐藏在了系统菜单图标。并且建议我将这个行为该为非默认，同时提供一个选项给用户，让用户对这个行为自行选择如何做。
审核人员的这个建议在我看来明显就是一个过渡设计。因为对于存在系统菜单图标的应用来说，点击窗口的关闭按钮之后，应用隐藏到系统菜单图标这件事本身，就是通用做法。因为如果点击窗口的关闭按钮之后，应用就完全退出了。那我制作系统菜单图标还有什么意义呢？而且我的应用也不是无法退出。在应用显示的情况下，使用系统默认cmd+q或者菜单中的“退出 咕唧”，应用都是可以正常退出的。
我将我的想法回复给了审核人员。审核人员还是坚持己见。我见到他如此坚持，就回复他说，如果这个我们没发达成一致，那我就只能上诉了。结果审核人员毫无惧色，甚至直接回复了我上诉的链接。
我开始意识到有些不对。这上诉是不是有什么猫腻啊。怎么这审核的这么积极呢？不过既然说了，那就得做。于是我就这个应用审核被拒进行了上诉。在上诉中我提到，我这个应用被拒的特性，几年前就通过了，这么多年来其他审核的人员从来没有就这个特性提出任何异议。直到这次。
9与25日半夜10点08分，我获得了苹果审核团队的自动邮件，告知我上诉已经收到，将尽快调查并将结果告知我。
说是尽快，但是十天了都还音讯全无。苹果没给我电话，也没有发邮件给我。这是被冷处理了？
2022年10月5日上午7点19分，我回复了苹果的那封所谓尽快的邮件。询问苹果10天过去了，有结果了吗？结果这封邮件石沉大海，没有得到任何回复。
我一看这样不行啊。上诉没结果。之前的应用被拒没解决。我的新版已经被挡住10天了。于是我决定自救。修改版本号之后，重新上传了一个新版要求再次审核。
有趣的事情来了，我这新版上传之后，10月6日半夜9点30分，苹果的审核团队主动给我发了一封邮件。说注意了我又上传了一个版本的应用，并说会审核这个应用，然后说如果再次被拒了，直接和审核人员沟通即可。
说得挺好，结果这个版本在进入“审核”状态之后，48小时都没有通过。也没有任何反馈。这在我看来，就是出问题了。于是我在10月8日上午7点33分，回复了审核团队的邮件，我说已经审核超过48小时了，能不能加速一下？这封邮件没有收到任何回复。
没办法，我只能手动撤销审核，然后又重新上传了一个不版本进行审核。这个版本审核人员找个小理由拒绝了。我修改了应用之后，又上传了一个版本。这个版本没有被找理由拒绝，但是又开始了多天“审核”的状态。就是进入“审核”之后就出不来。
10月18日上午7点48分，我给苹果的审核团队再次回复邮件。用的还是他发给我的那个说注意到我新上传了新版的那个邮件。我问，上诉的结果是什么？我非常关注这个上诉的结果，是因为它现在阻挡了我应用进行审核。对于我的新版应用，应用处在“审核”状态好几天了。我想不出任何原因为什么会出现这个问题，除了这个上诉。所以必须给我一个上诉的结果，什么结果都可以。不然我只能再次上诉了。因为这个无穷无尽的审核是不可接受的。
10月18日半夜10点32分，我收到了苹果的回复。说是已经将我这个问题提升了权重给苹果内部团队。说我这边无需采取任何操作。
于此同时，我发现我的应用已经审核通过，就等我手动发布了。
所以这次上诉应该就算告一段落了。苹果虽然没有给我一个明确的上诉结果。但是我的应用特性在未修改的情况下，新版得到了审核通过。这也算是支持了我的理念了。不过整体花费的时间将近一个月，还是挺浪费时间的。
为了写这篇文章，我花掉了136元。
最近考虑给iOS应用添加广告。首选当然是Google的Admob，可是申请的时候我才发现。我的常用Gmail曾经申请过Admob，但是由于后来没使用，账号被停用了。需要激活。重新激活的最后一步，总是提示错误。
好在我还有另外一个Google账户，结果这个账户在注册的最后一步，也总是遇到错误。
实在没办法了。去淘宝吧。淘宝找到一个商家说是可以帮忙验证地址，价格100块。他倒是把我的账户给注册成功了。但是网页我还是打不开，一直转圈。我问他，他说需要代理开全局，我说我已经开全局了啊。问他还有别的办法没有？他让我下载一个微软的远程桌面。我以为他要协助我处理。结果安装完了之后，他说可以去云厂商那里申请一个远程主机，然后用远程桌面登陆。还说他用的是腾讯云的。碰巧，这时，我的网页突然能上去了。我确认了一下，就给他付了款。
到了昨天下午，我又想上的时候，发现还是转圈，网页上不了。于是我开始研究这个远程桌面。
apt install xfce4 xfce4-goodies
apt install tightvncserver
vncserver
按照提示输入密码，vnc不需要用户名，只有一个密码需要设置。
先杀掉之前的vnc实例。
vncserver -kill :1
备份并新建文件
mv ~/.vnc/xstartup ~/.vnc/xstartup.bak
nano ~/.vnc/xstartup
内容如下：
#!/bin/bash
xrdb $HOME/.Xresources
startxfce4 &
给新文件加上运行属性
chmod +x ~/.vnc/xstartup
#!/bin/sh
vncserver -geometry 1920x1080 -depth 24
#!/bin/sh
vncserver -kill :1
给两个脚本分别加上运行属性
chmod +x start.sh
chmod +x stop.sh
每次运行vncserver都会新建一个实例，顺序按照1、2、3、4类推。所以需要kill掉旧实例。
ufw allow 5901
我使用的是VNC Viewer，只需要输入ip地址后面跟上:5901，然后在弹出的界面输入密码就可以了。
由于我的VNC只是偶尔需要用一下，我没有设置成系统自启，而是需要时通过start启动，用完了用stop杀掉，这样比较安全。
admob应该是为了防止有人骗点击，所以对于用户的ip审核比较严格。当我们翻墙时，即使使用了全局代理，但是原本的上网的ip还是能够检测到的。因此，admob认为这样的环境不合格。但是这其实是扩大化了。
另外，如果你使用的Firefox或者Safari等非Chrome的浏览器，admob甚至直接会显示网页错误。只有Chrome才不会显示错误，一直转圈圈。
当使用VNC之后，我用Firefox就能正常上admob了。因为VNC相当于是直接从云主机登陆。虽然IP地址和翻墙的一样，我使用同一台云主机。但是此时admob就能过了。
我使用的是腾讯云的36元一个月的主机。结果安装成功之后，我又在我原本翻墙的主机上试了一下，通过vnc一样能上admob。可见，能不能上的关键，不是主机所在的位置，而是你上网时浏览器的环境。如果是翻墙上，就会被拒。如果vnc直连，就没问题。
从8月17到8月31日，历时半个月，终于搞定了我的第一个订阅的新应用。期间遇到好多之前非订阅应用审核时没有过的新问题。在这里小结一下。
第一版遇到了三个问题。
审核人找不到应用内购买的页面。
应用支持开机自启，默认是开启的，可以在设置里关闭。苹果不允许，要求默认不支持开机自启，然后询问用户是否开机自启。
不符合订阅全部条款。
另外，苹果的这条审核建议的说明存在误导性。它提到的meta，指的是App Store Connect网站上，应用界面中的设置EULA的位置。那个位置默认就是上面提到的标准苹果使用协议。所以，真正有问题不是它建议的修改那里。而是将你的应用中的订阅页面，添加这个协议的链接。就像苹果的设计指南建议的那样。
添加了苹果要求的功能之后，我上传了第二版，结果还是又被拒了。这个被拒我与苹果交流5轮。前面的几轮，主要是上面提到的问题3，EULA的问题。因为当时我还没有意识到的苹果建议的误导。所以我一直在修改App Store Connect中的EULA的位置。我甚至还修改它为自定义EULA，结果苹果还是说不行。
直到最后，苹果给我发过来一个链接，让我按照上面的进行设计。我才发现，原来苹果要的其实是在订阅界面同时显示用户协议。
期间，我还遇到一个苹果自身的bug。重新提交版本的问题。按照之前的审核流程，如果你的审核是meta被拒，那只需要修改meta，然后等审核人员继续审核就可以。如果是二进制包被拒，就需要重新上传新版应用，然后再次排队审核。但是这次。我提交了新版的包之后，居然提交审核的按钮是灰的。
这一度导致我以为苹果是不是修改了审核流程。最后我发现，需要先在审核里点击取消当前版本的审核，新版的上传的提交审核才能点击。
我询问苹果审核人员，是不是必须这么做。因为这么做和之前的审核不太一样。苹果审核人员没有正面回答我这个问题。而是给我两个链接，让我自己学习苹果的审核流程。
几天苹果悄悄修复了我上面提到的那个问题。😮💨现在只要提交新版就可以点击审核了，就像过去一样。
这个版本有三个问题。
这个版本的审核显示出苹果审核人员的不专业性。最初他说我的应用显示的购买价格，和App Store Connect里设置的不一致。
这个其实根本不可能。因为我框架是RevenueCat，它基于苹果的StoreKit，获取的价格就是直接苹果服务器提供的。我向苹果进行了说明，还给他截了个图，和他我认为这个价格是相同的。
苹果启动重新审核，然后通过了这个版本。
我本以为这就可以了，终于可以上架了。然后我从商店里下载了我的应用，点击使用高级版。结果我发现，居然接收不到苹果服务器发来的订阅价格。
我打开App Store Connect，结果发现苹果只通过了我的主程序，订阅居然还是拒绝的状态。因为订阅是拒绝的，所以应用就没发从苹果的服务器获取订阅的信息，这在用户看来，就是我的应用出现了问题。这简直太坑人了。
这个问题明显是苹果审核人员，甚至是审核系统的问题。因为我的应用是第一版，订阅就应该和审核一起通过。结果苹果只通过了主应用，没通过订阅。这将导致我的应用的可用性降低。而这种问题，审核系统应该给审核人员提示，避免这种低级错误的产生。
第四版通过之后，我才发现，如果只提供一种按月订阅的方式，每个月发给自己兑换码太麻烦了。于是我又增加一个年费订阅的方式。这样只需要每年给自己提供一个兑换码就可以了。😄
第五版我特意标注了是为了苹果审核人员给我订阅进行审核才提交的。结果这个版本很快就通过。但是审核还是拒绝的状态。
我现在别无他途，只能找苹果求助了。我发邮件给苹果审核客服，要求单独审核我的订阅。结果回我说，我的应用已经通过了啊，不需要审核。我说我要求审核的是订阅，不是主应用。经过几轮之后，订阅还是没通过的状态。
这里说一下，我遇到的订阅的问题，主要有两个，一个本地化的meta，显示被拒绝，这个修改一下就可以了，然后显示的是等待审核。
另外两条，显示的都是需要开发者操作。这个需要开发操作，我在网上找到的办法都说，只需要加个逗号或者空格，然后再改回去就可以了，然后点击审核就可以了。但是我这里遇到了苹果的bug，无论我怎么修改，如何修改，那个需要开发者操作总是不消失，而再次审核的按钮也一直是灰的。
这一度让我想放弃，我发邮件给苹果，说明了这个情况，然后询问苹果我是不是需要删除了这个订阅新建一个才可以？
苹果没有回复我这个邮件。但是几天后，我发现我这两个订阅都已经显示审核通过了。
然后我打开我的应用，发现可以获取订阅信息了。但是只有月费订阅的信息，年费的还是看不到。
于是我更新了一下第三方框架，提交了第六版。
第六版当天就审核通过了。下载回来后，我发现，终于可以显示全部的订阅了。
这期间，我还遇到了苹果商店的其它的严重问题。这个发生在我的另外一个应用咕唧上面。
大家知道，Xcode在打包应用时，会使用Xcode自动生成的第三方证书对应用进行签名。大概20号左右，我收到了苹果的邮件，提醒我Mac的第三方证书将在30天后过期。我想，还不急，等过期了再更新就可以了。
其实更新很简单。就是Xcode点击新建第三方证书就行了。我没弄，结果就出问题了。
22号左右，我更新了咕唧的一个新版。结果苹果直接给我拒了。说我的应用有两个问题：
我一看就知道这明显是苹果的审核系统的bug。因为我是用Xcode打包的，怎么可能没有签名呢？而且我没有使用沙箱，也不可能，因为我根本没有改变这个设置。并且我用系统自带的活动监视器，查看我的运行的TestFlight版本的应用，也提示这个应用使用了沙箱。
而且我记忆中隐约有印象，类似的问题几年前出现过。也是第三方证书临近过期的时候出现的。
我在Xcode里新建了一个第三方证书，然后修改了应用版本号。重新打包提交，结果这个应用就被通过了。
这证实了我的怀疑。苹果的审核系统存在bug。当第三方证书时间小于30天时，苹果的审核系统将拒绝应用。我将这个bug提交给了苹果反馈。
大约两周前，工商银行客服给我打来电话，推荐我办理他家的信用卡。我想，那就办一张吧。一周后，收到了卡。又过了几天，我收到一条短信，说是工商银行的卡绑定微信会有优惠券。我想到我还有张信用卡没激活呢。那就激活看看吧。
按照提示下载了“工银e生活”App。我其实很不爽这些银行，干嘛银行卡和信用卡非要用不同的App。然后按照步骤激活，结果发现不能激活。看到说明下面有一行字，说是电话或者网上申请的信用卡，首次激活，必须去营业网点。真是坑！
17号到了营业网点，终于激活了。回家！
我这个人，不太习惯带钱包。都是把银行卡和身份证、公交卡、零钱之类的用一个小夹子夹起来就完事了。那天坐的是公交车。上车之后，第一遍刷卡，没响；又刷一遍，还是没响。公交司机说你的卡没钱了。我说还有好几百呢啊。他让我把公交卡拿出来单独刷，这次终于机器响了。大家记住这一幕。我一共刷了3次。这里有大坑！
回到家，打开信用卡App，发现已经产生了3.6元的费用。但是这个信用卡App却看不到明细。这个3.6元到底是怎么产生的呢？
今天，我想我可以去工商银行的网站上看明细。登录官网需要用手机银行刷码。结果刷完码我发现可以直接用手机银行查看信用卡的明细。信用卡推荐的信用卡App不能看明细，但是信用卡没推荐的手机银行可以。太坑了！
根据说明，这3.6元是两笔1.8元的地铁扣费。当然我那天没坐地铁，坐的是公交车。也就是说，我那天划卡时，虽然机器没响，但是钱扣了。所以我那天付了3份钱，信用卡扣了两次，公交卡又扣了一次。实在是坑！
于是，我打电话给工商银行客服。第一个客服，在知晓了我的情况之后，和我说她没权限给我拒付，需要要转到上一级的客服。第二个客服和我说，他可以帮我拒付。但是银行拒付周期长，而且还需要调查。调查之后如果认为我不符合，不仅不能拒付，而且每一笔还有收取10元的调查费用。问我是否能接受。我当然不能接受了。这也太坑了。
我和他说，首先，我根本不知道你们这个信用卡有这个公交卡的功能。上一个客服还和我说，公交卡需要绑定才能具备这个功能。但是我什么也没绑就自动开通了。其次，你们这个卡扣费了，但是机器不响。机器不响，人家公交司机就不认扣费成功。那我就需要再次划卡。这才是导致这次问题产生的原因。问题的产生根本不在我，而你们还要我付这个调查的费用。我当然不能接受。
银行客服于是承诺要向上反映这个问题。说是3天之内给我答复。我真是挺无语的。不过是接个电话，办了张卡。结果多出这么多麻烦事。真是太坑了！
之前一直我在Mac上一直使用的是ClashX，然后在手机上使用的是小火箭。这次为了调试新应用的功能，我需要在路由器上安装Clash。
小米的官方固件是不支持Clash的。但是由于它的官方固件基于OpenWRT，所以只要我们获得了SSH权限，就可以通过远程登录来安装自己需要的软件。获取SSH权限的操作，是通过特定版本的官方固件的漏洞来实现的。而最新的官方固件已经没有这个漏洞了，因此我们的第一步就是检查路由当前安装的固件版本。
原以为20.04的安装会比18.04方便很多。但是没想到坑也不少。
Ubuntu 18.04自带的Nginx本身没有开启ngx_stream_ssl_preread_module。我们安装Nginx官方提供的版本，这个版本开启了所有的可开启扩展。
sudo vi /etc/apt/sources.list
在文件最下面添加并保存
# for latest nginx
deb http://nginx.org/packages/mainline/ubuntu/ focal nginx
deb-src http://nginx.org/packages/mainline/ubuntu/ focal nginx
添加服务器签名，签名在这里nginx_signing.key。
wget http://web.archive.org/web/20180805232520/http://nginx.org/keys/nginx_signing.key
sudo apt-key add nginx_signing.key
安装Nginx并开启防火墙端口
因为防火墙默认是关闭的，所以ufw的那步可以不做。
sudo apt update
sudo apt install nginx
sudo ufw allow 80
sudo ufw allow 443
sudo systemctl start nginx
sudo systemctl enable nginx
你现在可以打开浏览器，然后输入vps的ip地址，如果看到了nginx的欢迎界面，就代表nginx配置成功了。
单独安装的nginx，只包含一个最基本的配置，多站点的文件夹默认都没有配置。我们需要手动建立文件夹。
mkdir -p /etc/nginx/sites-available
mkdir -p /etc/nginx/sites-enabled
然后编辑nginx.conf文件，将后者加入其中
vi /etc/nginx/nginx.conf
在include /etc/nginx/conf.d/*.conf;，之后插入一行，粘贴include /etc/nginx/sites-enabled/*;。
保存并退出。
假设你有一个网站叫example.com，网页位置在/var/www/html/example.com/html。新建一个配置文件。
sudo vi /etc/nginx/sites-available/example.com
内容如下
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
root /var/www/html/example.com/html;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
我们不用添加443端口，因为等下添加证书的时候，Certbot会帮我们自动生成新的配置文件。
将网站配置生效
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled
sudo systemctl reload nginx
参考上面的步骤，添加你所有的站点。之后，再额外添加一个站点，用于Trojan的识别。
最后添加的站点，一定要是一个不需要用的二级域名，而不要使用一级域名。因为我发现Nginx的预读有bug。如果你使用了一级域名，那么它的二级域名也都会匹配。这将导致错误。
一级域名指的是example.com这种，二级指的是mail.example.com这种。
这里我们假设额外配置一个叫tro.example.com的二级域名站点。
通过浏览器访问网站https://certbot.eff.org，选择Nginx和Ubuntu 20.04，安照网站的提示安装certbot。
sudo apt update
sudo apt install snapd
sudo snap install core; sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
申请证书
sudo certbot --nginx
按照提示进行操作。完成之后，你再通过浏览器访问网站，你会发现已经是https的了。
cd /etc/letsencrypt/live/
ls
记住证书所在的文件夹名称，假设是“example.com”。
虽然20.04自带了trojan，但是经过我的测试，20.04自带的trojan无法与nginx共同运行。trojan无法正常启动。所以，我们还是通过老办法进行安装。
如果你尝试了自带的trojan。自带的安装之后，配置文件在/etc/trojan。而不是/usr/local/etc/trojan。
sudo bash -c "$(curl -fsSL https://raw.githubusercontent.com/trojan-gfw/trojan-quickstart/master/trojan-quickstart.sh)"
sudo vi /usr/local/etc/trojan/config.json
找到"local_port"，将443，改成4433或者你希望的端口。
找到"password"，修改为你想要设置的密码。
找到"ssl"，将"cert"设置为“/etc/letsencrypt/live/example.com/fullchain.pem"。将"key"设置为"/etc/letsencrypt/live/example.com/privkey.pem"。
保存并退出。运行Trojan。设置为开机启动。
sudo systemctl start trojan
sudo systemctl enable trojan
sudo systemctl reload trojan
如果命令不返回任何消息。证明trojan正常启动了。如果提示没有在运行的trojan，无法重载，就证明trojan没有启动。
sudo vi /etc/nginx/nginx.conf
在events和http两段之间，插入
stream {
map $ssl_preread_server_name $name {
tro.example.com trojan;
default nginx;
}
upstream trojan {
server 127.0.0.1:4433;
}
upstream nginx {
server 127.0.0.1:4443;
}
server {
listen 443;
listen [::]:443;
proxy_pass $name;
ssl_preread on;
}
}
保存，修改之前设置的所有网站的设置。打开/etc/nginx/sites-enable/中所有的网站的配置，将所有的443端口，改成4443端口，然后保存。
sudo systemctl reload nginx
在好多支持Trojan的客户端中，域名是可选的。但是由于我们需要使用域名来进行跳转，所以在设置客户端时，域名是必填的，必须填写为
tro.example.com。
Module ngx_stream_ssl_preread_module
进入/etc/nginx/sites-enabled/目录，修改其中的每个文件。
cd /etc/nginx/sites-enabled/
sudo vi example.com
将其中的
listen [::]:4443 ssl; # managed by Certbot
listen 4443 ssl; # managed by Certbot
改为
listen [::]:4443 ssl http2; # managed by Certbot
listen 4443 ssl http2; # managed by Certbot
找到include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot，注释掉，并在下面添加新行。
# include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always;
保存并关闭。重新加载nginx。
sudo systemctl reload nginx
退出SSH与服务器的连接。在终端输入
curl -I https://example.com
输出结果如果有“HTTP/2 200”，就代表HTTP/2设置成功了。
我的iCloud只买了50G的，其中iPhone和iPad的备份占了大头。终于有一天，提示空间不够了，要加钱。于是我选择手动备份iPad，但是我发现，苹果默认备份是在主磁盘，并且没有改存储设置的选项。让一个很少用到的备份，占用主磁盘，实在是太不划算了。于是我查找修改的办法。
访达中默认备份的位置是~/Library/Application\ Support/MobileSync/Backup文件夹。我们只需要将这个位置通过ln转移到我们需要的位置即可。
~/Library/Application\ Support/MobileSync/，跳转到这个文件夹。/Volumes/1T/MobileSync/Backup/。ln -s /Volumes/1T/MobileSync/Backup/ ~/Library/Application\ Support/MobileSync/Backup。