但是你的内置屏幕旋转后大黑边问题，我不太了解，我觉得是分辨率设置不到位，所以才会留黑边。
另外就是，内置屏幕旋转之后你怎么使用？难道将 macbook 像一本书一样竖着放去看屏幕使用？有点奇葩

macos 一键切换横竖屏（分辨率、刷新率...）需要安装一些工具和编写脚本，我这里可以提供。
你需要先安装 homebrew , 然后使用以下命令进行安装和使用
```bash
# 安装
brew tap jakehilborn/jakehilborn && brew install displayplacer
# 查看
displayplacer list
```
以我得为例，我有两个显示器（内置+外置），所以最后会显示这样一段配置命令：

displayplacer "id:CD734E9A-7030-FBE1-D6EB-D493D1CCC796 res:1680x1050 color_depth:4 enabled:true scaling:on origin:(0,0) degree:0" "id:0E89A38C-1F87-6851-6F11-2497A1657713 res:2560x1440 hz:59 color_depth:8 enabled:true scaling:off origin:(1680,0) degree:0"

一般第一个("CD734E9A-7030-FBE1-D6EB-D493D1CCC796")就是内置的显示器配置，而"0E89A38C-1F87-6851-6F11-2497A1657713",则是第二个外置显示屏。

你可以通过 mac 的显示器偏好手动调整你的显示器设置，然后执行 displayplacer list 命令后，复制其配置信息，将其封装成 bash 脚本：
```bash
funcion screen_vertical() {
# 垂直的配置，以我得为例，我将外置显示器垂直 90 度 -> degree:90
displayplacer "id:CD734E9A-7030-FBE1-D6EB-D493D1CCC796 res:1680x1050 color_depth:4 enabled:true scaling:on origin:(0,0) degree:0" "id:0E89A38C-1F87-6851-6F11-2497A1657713 res:2560x1440 hz:59 color_depth:8 enabled:true scaling:off origin:(1680,0) degree:90"
}

function screen_horizontal() {
# 默认/横向的配置，第一次执行 displayplacer list 时显示的配置，或者你可以再次调整出正常配置后执行 displayplacer list 再看一遍 -> degree:0
displayplacer "id:CD734E9A-7030-FBE1-D6EB-D493D1CCC796 res:1680x1050 color_depth:4 enabled:true scaling:on origin:(0,0) degree:0" "id:0E89A38C-1F87-6851-6F11-2497A1657713 res:2560x1440 hz:59 color_depth:8 enabled:true scaling:off origin:(1680,0) degree:0"
}
```

把上述 bash 放到~/.zshrc(zsh shell) 或者~/.bashrc(bash shell) , 一般现在 macos 用的是 zsh shell, 这样你开机之后就可以直接再终端直接使用 screen_vertical 和 screen_horizontal 切换显示器(垂直/横向)配置。

做到这里也只是完成终端/脚本切换。

可以通过自定义快捷键触发脚本，我这里使用的是 Alfred (想象大部分 mac 用户都会安装它)

打开 Alfred 的配置，点开 Workflows ，在左侧面板最下方点击 "+" 号，添加一个自定义的 workflow （添加时问你创建的模板，选择 Blank Workflow 即可），然后基本上填写 name 然后点击 create 即可。

右击空白处点 Triggers->Hotkey ，创建一个 hotkey 触发方式，里面设置自己想触发的组合快捷键
继续右击空白处点 Actions->Run Script ，在 Script 处追加一行命令，比如 screen_vertical 或者 screen_horizontal 然后保存

然后再用鼠标将面板上的两个组件连接在一切，这就完成了一个快捷键切换配置，你可以同样的方式再添加一个 workflow ，来完成不同快捷键切换不同配置（横竖屏）

如果你的 nas 可以使用 shell 并且有权限的话，完全可以在 shell 中安装软件或者自行编写脚本解决你的问题。而且你都说了未下完就断开了，那应该是你已经可以这么做了。这个问题在非会员的网盘中经常出现，尤其是垃圾百度网盘，不但会断开，而且下载速度慢得离谱，需要你自行写逻辑续存

我查了一下阿里云有直接容器云的服务，你索性就使用这种，用容器按需部署，这样既可以使用 serverless ，又不需要将每个服务接口单独构造 serverless 函数

serverless 仅适合那些诸如体量小，任务独立，冷启动，时延要求低的服务，更准确来说是一个个独立且容易隔离的任务，这些任务每个都可以成为单独的脚本工程来维护，而不是一个大项目工程。如果你目前已经开发出一套服务，就没必要再次迁移到 serverless 了。

pm2 做负载均衡意味着你的服务是支持多进程无状态，所以可以在这个基础上挂个流量网关：nginx 或者 lb 服务配合一些脚本做弹性伸缩。

我理解一下你的意思：你们由于 5~6 台计算机需要自行录制桌面（桌面监控），同时将录制进行中的文件使用 smb 协议传到黑群晖中备份供审计，但同时进行的话，每台计算机都会非常卡，且发现黑群晖性能占用率不高，带宽占用大概在 100M 。是这个意思吧？

如果是，那么意味着录制的过程中出现黑群晖文件写入瓶颈，所以即使几台独立的计算机在一起同时录制时会卡顿。可以尝试录制完成后分块错峰上传。或者检查下黑群晖硬盘写入瓶颈

@demonkhh 这里有一个非商业性质开源的 flutter 项目，技术栈上对前端非常友好，因为是全离线的客户端程序。
sudoku-flutter 是一个完整交互功能的数独应用，且可以完全离线生成各种难度的数独。最新版本新增了可以 AI 识别数独图片和解题功能。
部分 UI/UX 交互还可以进一步完善，如果你感兴趣的话可以跳转到 gihub 上查看项目内容以及下载体验最新版本的 apk 。
github 地址 ： https://github.com/einsitang/sudoku-flutter

综合 star 和 issue 数量来选择

@GOliberation 这里有一个开源版，但是 flutter 实现，且仅支持移动端的版本： https://github.com/einsitang/sudoku-flutter

如果不需要应用还可以使用单纯算法的开源 lib ，有 nodejs / dart / go 语言的支持

@x86
玩法上可以一直迭代啊，比如加入道具，“隐身”（让“鼠”在地图上短暂消息），“禁锢”（让某个玩家在一定时间内不能离开某区域）；加入徽章成就系统：“逃脱大王”，“终极猎手”，“守株待兔”等等，诸如此类可以继续迭代升级
而且这类 LBS 应用很适合社交，容易交友，且还是线下真实交友。
商业上也很容易，比如游戏内道具的获取可以通过一些商铺（ KFC/喜茶/霸王茶姬/星巴克等实体品牌门店）完成简单的任务（比如扫码打卡），也可以发展周边。
这些都是我在脑海里就可以构思出来的，而且我相信还可以发挥更多

比较困难，毕竟磁力链接提供的不是流媒体，现在的边下边播是将文件下载一部分到本地才可以正确解释，线上的流媒体格式和这种不一样，体积也不一样

@muzuiget @shellus 你们不需要考虑中间人问题，因为这个问题的建立是在“当时 http 盛行”的环境内。这个只是改良登录传输密码的环节，所以你应该对比的是“直接传输密码” vs “签名隐藏密码”的安全差异。

这个问题主要在于，为什么当时连这个改良都没有

防盗链，但这个仅对 web 图片有效。

如果是文件分享的话，可以加一个请求授权流程，每次都向你的服务请求授权链接，然后你可以按需要给 oss 文件生成有时效的访问 URL ，这样你可以在你的服务端做相关的检查了

@i8086 那可能是我孤陋寡闻了

@tool2d 哈哈，可能是我孤陋寡闻了，因为当年我在参加工作的时候没有考虑到这么多，同时也没有任何人或者在任何团队上看到这种方式，所以完全没有看到这方面的应用，直到现在突然联想到这个问题发现当时没人这么做非常不合理。原来早就有了啊。。但是没有大规模形成实现标准，这也非常不合理啊

@flyqie 在那个年代，成本显然是低于 ssl

这种产品应该有很多啊，不过我不是做客户端开发的，所以不清楚具体的选型有哪些。

不过以前客户端的同事(Android/iOS) 都会接入这类似的平台，这些平台的 SDK 会帮忙收集客户端产生的日志，只是大部分情况下不会主动且实时上报到平台，而是本地记录，作为技术统计用的，当出现错误崩溃时也会记录错误日志栈，之后会将这些日志再上传到平台，所以他们可以在平台上通过错误栈和搭配其他统计信息进行远程 debug 。

所以主要区别是在于追踪非实时，并且只监测不控制。而我觉得这种方式更为合适，因为对于用户层面上来说，因为需要 debug 产品而对程序进行控制并不厚道，对于工程师来说，他们关注的点应该是出错信息而不是对于每一个客户端设备 debug ，所以只监测不控制，也不需要实时监测

2KSMNDH7IN8PT048 已用

@andyzhshg sudoku-go 有应用 DLX 的算法，只是在常规状态下速度不及 DFS ，只有在高难度的题目上才能有些许提升