Docker 构建服务时频繁被 Killed 谁懂啊！最近用 WisdomSSH 部署 api 服务，执行 docker-compose up -d --build api 总失败，一度卡壳到没思路🤯 还好靠 WisdomSSH AI 运维助手的协同排查，顺利搞定了！​
我先向助手求助 “资源不足被 killed 咋让编译通过”，它立刻指引我查系统资源，一起执行 free -h 后真相大白：服务器只有 1.8GB 内存还没开 Swap，Go 编译阶段内存直接耗尽，Linux 内核就把进程终止了！​
试过停非关键服务还是不够，助手又给了根本方案 —— 创建临时交换空间，还直接甩来可执行命令：dd if=/dev/zero of=/swapfile bs=1M count=2048 && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile，一键搞定 2GB 交换空间​
再次验证资源后重新构建，162 秒就成功生成镜像启动服务！这次真的感受到 WisdomSSH 的实力，不仅精准定位内存不足的核心问题，还给了即拿即用的应急方案，把棘手难题拆成清晰步骤，效率直接拉满。​
给运维小伙伴提个醒：遇到构建被突然终止，先查内存和 Swap！临时加交换空间是超实用的应急办法，能稳稳保住部署流程不中断～

问大家个权限相关问题：

员工表：后台管理系统登录使用
会员表：小程序to-c登录使用

需求：
小程序端有个功能模块只能后台人员使用，普通会员看不到
提问：
不在小程序设置例如 (我是用户、我是管理员)类似双入口登录，如何实现？

最近与人沟通，思考一个问题，搞开发，往主会遇到工期紧的情况，但真正原因是什么？
大部分人都在找外部原因，比如：上面安排的时间不合理，需求没讲清楚，沟通协作问题等，不可否认会有这类问题存在，但但凡有这类问题的人，往往不从自己身上找找原因，需求是否正确理解，边界是否确认清楚，设计是否合理，代码是否易于维护，线上问题收敛了没，等等，若一个系统能够做到线上问题极少，返工极少，需求做一个少一个，那么产品与技术之间形成互相信任，技术承诺都能兑现，产品就不必用时间压技术，技术不必疲于应付，和谐共处，遇事好商量，何愁工期问题？