习惯上我还是使用centos7.9x64的系统，由于所有的linux发行版的sshd服务默认端口都是22，所以一旦vps(或ecs)启动后就会受到大量的端口扫描和安全爆破。
为了杜绝这种安全隐患，把sshd的端口改掉会减少很多攻击，下面使用vi工具进行修改，默认都在命令行(终端)模式下执行，每行一个操作：
cd /etc/ssh/
vi sshd_config
找到port 22一行，去掉前面的#号，将22修改成12345
按ecs键，输入:wq回车即保存
执行systemctl restart sshd.services或service sshd restart将sshd服务重启，端口即改成了12345。
如果使用的阿里云服务器，需要ecs安全组中，添加一条将tcp 22345端口数据放行。
首先使用的是2017年我的一篇老贴的方法：
http://www.784533.xyz/archives/153/
结果是重启后进入安全模式列表，选任意一个就会死循环。
不行，后找到另一个方法：
https://www.cnblogs.com/codec/p/3540152.html
VBox虚拟机装XPsp3，设置了使用2个核，在XP“我的电脑”属性页也看到2个核，但任务管理器里只看到一个cpu。网上搜索了一下，解决办法：
在XP里运行命令“rundll32 syssetup,SetupInfObjectInstallAction ACPIAPIC_MP_HAL 128 %windir%\inf\hal.inf”后重启就OK了。
使用此方法重启后一样在xp启动时显示安全模式，然后死循环。问题应该是vbox7.x版本不支持，有空再用老版本试试。
更一：
https://zhuanlan.zhihu.com/p/652789532
智达云+powerBuilder(PB)
是针对建筑、装修、景观方面的增强型插件，很多实用工具减少手绘的工作量。
八宝库
有免费的材质素材、模型、PB构件库。
坯子库
坯子库本身是一套建筑使用的多种工具箱，墙体窗户楼梯栏杆等等。同时也是一个su插件管理器，有上百种插件集合，可以在应用内进行安装。
建筑学长
也是一个建筑相关的工具箱工具，同时也提供了免费的在线模型库和材质库。免费但有收费服务。
模型派
核心是几个不同的功能插件，有材质助手、灯光插件、模型助手、细节大师等，这是一个收费插件，提供了在线的材质库和模型库，目前各类不多还不及建筑学长。但是即使不用在线服务，使用此插件管理本地的材质和模型也是不错的。
阿歪梦工厂
有大量的勉强素材和模型，即使不充值也够大部分情况使用。
inventor2015和autocad2014安装时已经断网激活，但是一开网又会提示注册码不对，需要再次激活。
怎样防止再次激活？ 只要阻止其联网，再重新激活即可。
1. 禁止解析autodesk相关域名
找到c:/windows/systm32/drivers/etc/hosts文件，添加几行：
127.0.0.1 autodesk.com
127.0.0.1 uri.autodesk.com
127.0.0.1 accounts.autodesk.com
127.0.0.1 registeronce.autodesk.com
127.0.0.1 ELB-for-CIP20-ASE-PRD-828438764.us-west-1.elb.amazonaws.com
127.0.0.1 df-prod.autocad360.com
127.0.0.1 docs.autodesk.com
保存。
2. 禁止连接autodesk相关ip
以管理员运行c命令提示符，运行下面每一行：
route add 3.83.28.0 mask 255.255.255.0 1.2.3.4 -p
route add 3.224.10.0 mask 255.255.255.0 1.2.3.4 -p
route add 108.156.133.0 mask 255.255.255.0 1.2.3.4 -p
route add 50.19.149.4 mask 255.255.255.255 1.2.3.4 -p
route add 23.21.189.113 mask 255.255.255.255 1.2.3.4 -p
route add 169.254.169.254 mask 255.255.255.255 1.2.3.4 -p
ipconfig /flushdns
3.重新使用注册机激活即可。
size marker
Parker
specsV1.1
易米路由器是大约在2013左右，由于微信公众号的兴起，国内一个网络公司定制的用于wifi吸粉的无线路由器，使用openwrt定制，后台使用的是LuCI，其默认用户和密码是root / emee。
我手上有一台E-501型号，2.4g 300mbps，机器还不错，已稳定使用了10多年，可惜的是始终没有人做适配刷机。
在windows系统中一键递归获取目录下所有的文件名。
在某目录中新建一个lister.txt文件，填写内容tree /f > list.txt，保存成lister.bat。
双击运行，将会递归眼目录下所有文件名并保存在list.txt中。
一直以来，我都在自己的几台电脑上使用btsync1.4.111做文件的备份和同步，比如几个人同样做一份设计稿，我做前1-10页，B同事做11-20页，C同事做21-30页，我们只需要每人建一个psd文件，然后使用btsync挂机，每个人做的一部分都会自动同步到所有人，这样即是一个版本服务器同时也是个自动文件服务器。这种应用方式在局域网内可用，在地球的不同位置也一样同用，对于非代码类的团队的协同工作是非常好的。
大约在5年前，btsync1.4.111版本突然连不上服务器了，中途有一阵突然又可以连上但是打洞的成功率比较低，再后来就彻底连不上了。
起初，以为是因为墙的原因，电脑上的一些项目都依然保持着。直到很长一段时间，我意识到可能永远也连不上了，那么是否可以魔法工具来使用呢?
在网上找了很多文章来尝试，最终者是无果的，最近一次尝试是看了下面这篇文章。
Resilio Sync 无法连接解决方法
https://foair.me/posts/resilio-sync-connection
通过为btsync设置代理，结果也是不行的，但是为了验证官方服务器是否连上，我使用了Proxifier分析了一下软件启动时年连接过程，软件确实发起了连接，但是回包却是几串报错信息。由于新老版本使用的服务器并不同，意味着像btsync1.4.111这种老版本的官方服务器配置文件已经没存在了。
这就说到我为什么还在用1.4.111这个版本，是因为这个版本有dht功能，这个功能在一次连接后，可以通过已连接的节点获取到其它节点信息，对于p2p来讲这是一个很好的功能。
既然老版本的官方服务器配置文件已不可用，并不代表这个软件已不可用，在非公网的情况下btsync依然是一个好用的工具，下面按两种情况说说：
1.局域网中使用btsync
这里的局域网可以是公司内部的同一wifi和网段的，也可以是有\/pn连接的异地用户，只要电脑之间可正常通信即可。
假设在A电脑的btsync里有一个文件目录，我们在B电脑上使用分享过来的key添加项目，在此项目的偏好设置---预定义主机-指定A的ip和端口，即可连上并实现高速同步。
2.在公网使用btsync
如果你的电脑A有公网ip，直接从路由器把btsync使用的端口映射过去即可，从其它电脑上使用预定义主机指定这个A的公网ip和端口即可。
如果两边都是内网，那么你需要一台VPS，在VPS上运行一个btsync客户端，在VPS上运行一个项目，其它所有节点都使用预定义主机与这台VPS连接。
如果两边都是内网，但是又不想在VPS上面保存文件，仅做数据中转，那就需要使用像frp这样的工具，将VPS上面btsync客户端的ip和端口映射到电脑A，其它节点使用预定义主机指定VPS的ip和端口。
如此，可以将btsync老版本做为一个私有的使用继续使用。
Eloquent是laravel中用来实数据库模型化的工具，使用eloquent生成模型类，与数据表形成映射关系，之后在操作数据库时就不需要手工进行数据的边接和查义语句的编写，只需写php对模型类进行操作即可。
那么在laravel中，当我们在.env中配置好数据库后，laravel是否会自动生成建议映射并生成模型文件呢? 答案是不会的。
了解这个问题，其实就是了解Eloquent的工作过程。
通常情况下，你需要手工使用Artisan命令来生成Model，但这个命令可以非常智能地根据你的数据表结构进行“适配”，而不是完全“自动生成”。
系统不会在你创建数据表迁移后自动为你创建模型。你需要手动执行一个命令来创建模型文件，然后可以手动或利用命令选项来让它与特定的数据表关联。
核心概念：为什么不是全自动？
Laravel 遵循 “约定优于配置” 的原则。如果你遵循它的约定，几乎不需要额外配置。
模型命名约定：模型类名的单数、大驼峰形式对应数据表名的复数、蛇形命名。
例如：模型 Flight 会自动对应到数据表 flights。
模型 UserProfile 会自动对应到数据表 user_profiles。
主键约定：默认每张表的主键是 id，且是自增的整数。
时间戳约定：默认期望存在 created_at 和 updated_at 两个时间戳字段。
如果你遵循了这些约定，你只需要生成一个空的模型，它就能自动工作。如果你没有遵循约定，则需要在模型文件中手动指定表名、主键等属性。
如果我们有一个posts表，那么执行php artisan make:model Post即可app/Models/ 目录下生成 Post.php 文件。
高级技巧：一站式生成
Laravel 的 Artisan 命令非常强大，可以让你在创建模型的同时顺便创建迁移、控制器等资源，大大提高效率。
最常用的组合命令：
bash
php artisan make:model Post -mcr
-m 或 --migration：同时为模型创建一个迁移文件 (create_posts_table)。
-c 或 --controller：同时创建一个资源控制器 (PostController)。
-r 或 --resource：指示控制器应该是资源控制器（包含 index, create, store, show, edit, update, destroy 等方法）。
执行上面的命令后，你会一次性得到：
模型文件 app/Models/Post.php
迁移文件 database/migrations/xxxx_create_posts_table.php
控制器文件 app/Http/Controllers/PostController.php
然后你只需要去编辑迁移文件来定义表结构，再运行 php artisan migrate 即可。
建立好模型类文件，就可以在控制器或者路由中使用它了。
Migration 的核心作用是在多人协作中，像使用版本控制器（如 Git）管理代码一样来管理你的数据库，从而避免使用sql脚本文件的互传。
它允许你和你的团队在应用中定义、共享和维护数据库结构的变化，确保所有开发人员、测试服务器和生产服务器的数据库结构始终保持一致。
在没有迁移功能之前，团队协作开发时，数据库结构的管理通常非常麻烦：
开发者A 在本地数据库添加了一个新表或新字段。
开发者B 也需要进行同样的修改，他需要手动执行 SQL 语句或从A那里获取SQL脚本。
很容易出错，或者忘记执行某个修改，导致代码运行失败。
部署到生产环境时，DBA 或运维人员需要根据开发的变化，手动整理和执行SQL脚本，过程繁琐且易遗漏。
Migration 完美地解决了这些问题：
1. 版本化与协同工作
每个迁移文件通常代表一次数据库结构的更改（例如：create_users_table, add_votes_to_users_table）。
这些文件被放在项目的 database/migrations/ 目录下，可以纳入版本控制系统（如 Git）。
当其他开发者拉取（pull）你的代码后，只需要运行一条命令 php artisan migrate，Laravel 就会自动执行他们本地尚未运行过的迁移文件，使他们的数据库结构立刻与你的一致。
2. 数据库无关性
迁移让你可以使用 PHP 代码 和 流畅的、富有表现力的语法 来定义数据表结构，而不是原生的 SQL。
Laravel 的 Schema 构建器支持所有主流数据库系统（MySQL, PostgreSQL, SQLite, SQL Server）。
这意味着你写一套迁移代码，可以无缝地在不同的数据库驱动上运行，无需为不同数据库编写不同的 SQL 脚本。
示例：创建一个 flights 表
php
// database/migrations/2024_08_19_000000_create_flights_table.php
public function up()
{
Schema::create('flights', function (Blueprint $table) {
$table->id(); // 自增 ID，主键
$table->string('name');
$table->string('airline');
$table->timestamps(); // 自动创建 created_at 和 updated_at 字段
});
}
这段代码非常易读，并且可以用于创建任何支持的数据库表。
3. 可逆性（回滚）
每个迁移文件都包含两个核心方法：up() 和 down()。
up(): 用于执行新的更改（创建表、添加字段等）。
down(): 用于撤销 up() 方法所做的更改（删除表、移除字段等）。
这让你可以轻松地回退到之前的数据库状态。
常用回滚命令：
php artisan migrate:rollback: 回滚上一次的迁移操作。
php artisan migrate:rollback --step=5: 回滚最近5次迁移操作。
php artisan migrate:reset: 回滚所有已运行的迁移（清空所有表）。
4. 部署与同步
在部署应用到生产环境时，你只需要在服务器上运行 php artisan migrate（通常作为部署脚本的一部分）。
Laravel 会检查 migrations 表（该表由框架自动创建，用于记录已运行的迁移），然后只执行那些还未运行的迁移文件。
这确保了生产环境的数据库结构总是与代码库中定义的最新结构完全同步，极大地简化了部署流程。
5. 保持一致性
迁移强制要求团队使用统一的、定义良好的方式来修改数据库。
它成为了数据库结构变化的“唯一真相源”，所有人都基于这套迁移文件工作，避免了手动修改数据库可能带来的混乱和不一致。
