如果天空总是黑暗的，那就摸黑生存；
如果发出声音是危险的，那就保持沉默；
如果自觉无力发光，那就蜷伏于墙角。
但不要习惯了黑暗就为黑暗辩护；
也不要为自己的苟且而得意；
不要嘲讽那些比自己更勇敢的人们。
我们可以卑微如尘土，但不可扭曲如蛆虫。
——季业
所有由霜月发布的文章
一屋不扫何以扫天下.
在路边一个不起眼的小店里吃面，顺便和老板聊了会儿。谈及如今的生意，老板感慨颇多。他曾经辉煌过——兰州拉面最红的时候在闹市口开了家拉面馆，日进斗金啊!后来却不做了。问他为什么，他说：“现在的人贼啊!我当时雇了个会做拉面的师傅，但在工资上总也谈不拢。”
“开始的时候为了调动他的积极性我们是按销售量分成的，一碗面给他5毛的提成。过不多久，他发现客人越多他的收入也越多，这样一来他就在每碗里放超量的牛肉来吸引回头客。一碗面才四块，只图个薄利多销，他每碗多放几片牛肉我还赚哪门子钱啊!”
老板继续说：“后来看看这样不行，就每月发固定工资，工资给高点无所谓。这样他总不至于多加牛肉了吧?”“但你猜怎么着?”老板有点激动了，“他在每碗里都少放牛肉，把客人都赶走了!”
“这又是为什么?”轮到我激动了。老板回答：“牛肉分量少，顾客就不满意，回头客少，生意肯定清淡。他才不管你赚不赚钱呢，他拿固定的工钱巴不得你天天没客人!”
啊!尽管被管理者只有一个，一个好项目还是因为管理不善不得不退出市场。这可是第一手的实战啊!我把这个案例告诉了其他朋友。下面是一个博士，一个研究生，和一个MBA对这个问题的激辩：
1．首先我们考虑将小老板所用两种方案进行折中，即：底薪加提成的方法，提成根据每碗的利润分配。这样既可以防止他少放牛肉．又能防止他疯狂地多放牛肉。
2．后来又想到这一条是有条件的。问题是每碗牛肉的利润界定后怎么个分配法?一碗面能挣多少是瞒不过大师傅的，如果不能让双方的利益在某个点达到平衡，一切又会回复原样。
3．把面馆承包给大师傅，老板拿了提成回家养花弄鸟去。当然，提出这个方案后大家都有过短暂的脸红。再否定!
4．我们谈到了企业文化、正义、道德、人性，并一致认为：管理学博大精深，成为一个优秀的管理者非得经过百般磨炼方能修得正果，再先进的管理理论也有不适用的时候。
没想到，一碗牛肉面反映出一个小企业管理中的种种问题。
首先，关于大师傅的激励问题。我们可以设计一个激励机制，就是在定额约束下的销量或利润累积奖励。根据每碗面的顾客可接受程度制订一个用料定额，大师傅的工资还是按照销售量提成，但是前提是月度的牛肉消耗不得偏离定额太多，例如允许波动幅度为20％，否则只有基本工资。即是说规定每碗面需要添加的牛肉克数。一批牛肉的总量是固定的，拉面的卖出量是可以计算的。多少碗面放多少斤牛肉限定住了，哪个师傅敢给我多加或者少加，呵呵，工资就对不起了。再者，老板自己心里得算清楚一碗面的成本是多少?利润是多少?如果牛肉放多了，客户多了，以牛肉最大量为定量，以面条量为变量，控制一下放面条的多少使自己还有利润可赚。
其次，饭店也是制造，必须有工作程序、定额消耗以及制度规范。可以没有书面东西，但老板必须心中有数才行。对这个老板的拉面店来说，其实就是师傅以技术入股的方式和老板利润分配，大家都双赢。两个人合伙做，费用两个人摊，进行规范化管理。在工作程序上：比如制订面条的量、水的量、肉的量等明确规定，制造方法、工艺也请大师傅标准化；在定额消耗上，也与上述的激励密切相联；薪水报酬上，参考社会上的平均工资和本店的盈利水平，结合师傅的劳动量、劳动结果(营业额的升降、顾客的反馈等)进行综合评定。
要不，干脆将复杂事情简单化——让老板娘放牛肉不就得了?关键的资源一定要掌握在关键的人手里!老板掌握了店面的所有权，才可能有大师傅为他打工；老板娘掌握了牛肉的分发权，才有可能防止材料的浪费和滥用。不过，老板还应该再掌握大师傅这一核心的人力资源，怎么掌握还是一个难题……唉，人力资源。而且，作为小规模店铺，老板要熟悉每一个环节才能做好管理。如果牛肉拉面老板很熟悉牛肉拉面的制作，师傅也不敢乱来。有效的经营监督应该是这样。
另外，任何工作除了要有控制、监督，其余的事情都可以通过沟通来解决。本案例中没有任何一种办法能一劳永逸地解决分配问题。在这种作坊式的小企业里，老板与员工每天有大量时间接触，关系是否和谐非常重要。
通过以上分析，结论应该是这样：
1．底薪加提成，提高积极性；
2．不能把全线流程的权力都下放给大师傅，比如加牛肉；
3．建立有效的制度，包括奖赏和惩罚，制度根据顾客的满意程度和利润来建立；
4．大师傅的工资提成不能只和销量挂钩．应该和老板的利润挂钩，比如一碗面中老板利润的30％是大师傅的利润；
5．有效的沟通、激励。
密码保护：一坑未填,一坑又现
论科学上网
当今互联网的三大月经之一就是谷歌可以直联,当GF*W间歇性内存溢出,或者reboot导致.但是话说回来,有些时候确实需要使用谷歌,想搜点技术类的内容或者专业点的知识.用百毒真的是难以满足 。如果真要使用谷歌搜索，那么请自行选择以下几套方案。
一。肉身越狱，此法简单粗暴，可以享受墙外之新鲜无污染空气，但是非一般人所能及。
二。hosts，此法相当于移花接木。将被污染的DNS解析的内容还原回去。优点呢就是方便,设置好之后,对其他没有任何影响.缺点呢就是现在可用IP是越来越少,基本上是见光死.
三。代理法，现在的常用的55R,55,9AE等各类软件,优点呢,稳点一点,缺点就是配置较为复杂,需要添加一部分白名单地址.
离线文件下载:
If you want to install Chrome for your own user account:
Download Google Chrome Standalone Offline Installer (32-bit)
Download Google Chrome Standalone Offline Installer (64-bit)
If you want to install Chrome for all user accounts:
Google Chrome Offline Installer for All User Accounts (32-bit)
Google Chrome Offline Installer for All User Accounts (64-bit)
如何通过搜索引擎快速找到你想要的
1、双引号
把搜索词放在双引号中，代表完全匹配搜索，也就是说搜索结果返回的页面包含双引号中出现的所有的词，连顺序也必须完全匹配。bd和Google 都支持这个指令。例如搜索： “seo方法图片”
2、减号
减号代表搜索不包含减号后面的词的页面。使用这个指令时减号[前面]必须是空格，减号后面没有空格，紧跟着需要排除的词。Google 和bd都支持这个指令。
例如：搜索 -引擎
返回的则是包含“搜索”这个词，却不包含“引擎”这个词的结果
3、星号
星号*是常用的通配符，也可以用在搜索中。百度不支持*号搜索指令。
比如在Google 中搜索：搜索*擎
其中的*号代表任何文字。返回的结果就不仅包含“搜索引擎”，还包含了“搜索收擎”，“搜索巨擎”等内容。
4、inurl
inurl: 指令用于搜索查询词出现在url 中的页面。bd和Google 都支持inurl 指令。inurl 指令支持中文和英文。
比如搜索：inurl:搜索引擎优化
返回的结果都是网址url 中包含“搜索引擎优化”的页面。由于关键词出现在url 中对排名有一定影响，使用inurl:搜索可以更准确地找到竞争对手。
5、inanchor
inanchor:指令返回的结果是导入链接锚文字中包含搜索词的页面。百度不支持inanchor。
比如在Google 搜索 ：inanchor:点击这里
返回的结果页面本身并不一定包含“点击这里”这四个字，而是指向这些页面的链接锚文字中出现了“点击这里”这四个字。
可以用来找到某个关键词的竞争对收，而且这些竞争对手往往是做过SEO 的。研究竞争对手页面有哪些外部链接，就可以找到很多链接资源。
6、intitle
intitle: 指令返回的是页面title 中包含关键词的页面。Google 和bd都支持intitle 指令。
使用intitle 指令找到的文件是更准确的竞争页面。如果关键词只出现在页面可见文字中，而没有出现在title 中，大部分情况是并没有针对关键词进行优化，所以也不是有力的竞争对手。
7、allintitle
allintitle:搜索返回的是页面标题中包含多组关键词的文件。
例如 ：allintitle:SEO 搜索引擎优化
就相当于：intitle:SEO intitle:搜索引擎优化
返回的是标题中中既包含“SEO”，也包含“搜索引擎优化”的页面
8、allinurl
与allintitle: 类似。
allinurl:SEO 搜索引擎优化
就相当于 ：inurl:SEO inurl:搜索引擎优化
9、filetype
用于搜索特定文件格式。Google 和bd都支持filetype 指令。
比如搜索filetype:pdf SEO
返回的就是包含SEO 这个关键词的所有pdf 文件。
10、site
site:是SEO 最熟悉的高级搜索指令，用来搜索某个域名下的所有文件。
11、linkdomain
linkdomain:指令只适用于雅虎，返回的是某个域名的反向链接。雅虎的反向链接数据还比较准
确，是SEO 人员研究竞争对手外部链接情况的重要工具之一。
比如搜索
linkdomain:cnseotool.com -site:cnseotool.com
得到的就是点石网站的外部链接，因为-site:cnseotool.com 已经排除了点石本身的页面，也就是内部
链接，剩下的就都是外部链接了。
12、related
related:指令只适用于Google，返回的结果是与某个网站有关联的页面。比如搜索
related:cnseotool.com
我们就可以得到Google 所认为的与点石网站有关联的其他页面。 这种关联到底指的是什么，Google 并没有明确说明，一般认为指的是有共同外部链接的网站。
上面介绍的这几个高级搜索指令，单独使用可以找到不少资源，或者可以更精确地定位竞争对
手。把这些指令混合起来使用则更强大。
inurl:gov 减肥
返回的就是url 中包含gov，页面中有“减肥”这个词的页面。很多SEO 人员认为GVM和学校网
站有比较高的权重，找到相关的GVM和学校网站，就找到了最好的链接资源。
下面这个指令返回的是来自.中国教育和科研计算机网CERNET，也就是学校域名上的包含“交换链接”这个词的页面：
inurl:.中国教育和科研计算机网CERNET 交换链接
从中SEO 人员可以找到愿意交换链接的学校网站。
或者使用一个更精确的搜索：
inurl:.中国教育和科研计算机网CERNET intitle:交换链接
返回的则是来自中国教育和科研计算机网CERNET 域名，标题中包含“交换链接”这四个字的页面，返回的结果大部分应
该是愿意交换链接的学校网站。
再比如下面这个指令：
inurl:中国教育和科研计算机网CERNET*register
返回的结果是在.中国教育和科研计算机网CERNET 域名上，url 中包含“forum”以及“register”这两个单词的页面，也就是
学校论坛的注册页面。找到这些论坛，也就找到了能在高权重域名上留下签名的很多机会。
下面这个指令返回的是页面与减肥有关，url 中包含links 这个单词的页面：
减肥 inurl:links
很多站长把交换链接页面命名为links.html 等，所以这个指令返回的就是与减肥主题相关的交换
链接页面。
下面这个指令返回的是url 中包含gov.cn 以及links 的页面，也就是GVM域名上的交换链接页面：
allinurl:gov.cn+links
最后一个例子，在雅虎搜索这个指令：
linkdomain:cnseotool.com -linkdomain:cnseotool.com
返回的是链接到点石网站，却没有链接到我的博客的网站。使用这个指令可以找到很多连向你
的竞争对手或其他同行业网站，却没连向你的网站的页面，这些网站是最好的链接资源。
高级搜索指令组合使用变化多端，功能强大。一个合格的SEO必须熟练掌握这几个常用指令的
意义及组合方法，才能更有效率地找到更多竞争对手和链接资源。
找外链的时候你可以用这几种命令组合，例如site:.com inurl:blog “post a comment” -”comments closed” -”you must be logged in” “输入你的关键词“，
site:.com 是 指， 只显示.com的网站。 如果你想要 org的链接，就换成 site:.org，inurl:blog 是指博客。
“post a comment” -”comments closed” -”you must be logged in” 是指， “能够写评论的” 减去“ 关闭评论的” 再减去“ 必须要登录才能写评论的”。
程序问题处理遇到的坑
- 能写成配置属性的字段就不要写死在代码里面,不要觉得写好的程序就不会修改.公共参数放配置文档,修改频繁放数据库,量大写内存,关闭时注销
- 遇到问题,要复盘.在问题出现的伊始解决掉.这样花费成本最小.
- 好记性不如烂笔头
- 新的一项任务,做之前要把最复杂的情况考虑到,再做设计.
SQL判断某列中是否包含中文字符、英文字符、纯数字
一、包含中文字符
select * from 表名 where 列名 like ‘%[吖-座]%’
二、包含英文字符
select * from 表名 where 列名 like ‘%[a-z]%’
三、包含纯数字
select * from 表名 where 列名 like ‘%[0-9]%’
SQL Server 触发器 的 增删改查
一: 触发器是一种特殊的存储过程﹐它不能被显式地调用﹐而是在往表中插入记录﹑更新记录或者删除记录时被自动地激活。所以触发器可以用来实现对表实施复杂的完整性约`束。
二: SQL Server为每个触发器都创建了两个专用表:Inserted表和Deleted表。这两个表由系统来维护﹐它们存在于内存中而不是在数据库中。这两个表的结构总是与被该触发器作用的表的结构相同。触发器执行 完成后﹐与该触发器相关的这两个表也被删除。
Deleted表存放由于执行Delete或Update语句而要从表中删除的所有行。
Inserted表存放由于执行Insert或Update语句而要向表中插入的所有行。
三:Instead of 和 After触发器
SQL Server2000提供了两种触发器:Instead of 和After 触发器。这两种触发器的差别在于他们被激活的同:
Instead of触发器用于替代引起触发器执行的T-SQL语句。除表之外﹐Instead of 触发器也可以用于视图﹐用来扩展视图可以支持的更新操作。
After触发器在一个Insert,Update或Deleted语句之后执行﹐进行约束检查等动作都在After触发器被激活之前发生。After触发器只能用于表。
一个表或视图的每一个修改动作(insert,update和delete)都可以有一个instead of 触发器﹐一个表的每个修改动作都可以有多个After触发器。
四:触发器的执行过程
如果一个Insert﹑update或者delete语句违反了约束﹐那幺After触发器不会执行﹐因为对约束的检查是在After触发器被激动之前发生的。所以After触发器不能超越约束。
Instead of 触发器可以取代激发它的操作来执行。它在Inserted表和Deleted表刚刚建立﹐其它任何操作还没有发生时被执行。因为Instead of 触发器在约束之前执行﹐所以它可以对约束进行一些预处理。
五:使用T-SQL语句来创建触发器
基本语句如下:
create trigger trigger_name
on {table_name view_name}
{for After Instead of }
[ insert, update,delete ]
as
sql_statement
六:删除触发器：
基本语句如下:
drop trigger trigger_name
七：查看数据库中已有触发器：
— 查看数据库已有触发器
use jxcSoftware
go
select * from sysobjects where xtype=’TR’
— 查看单个触发器
exec sp_helptext ‘触发器名’
八:修改触发器：
基本语句如下:
alter trigger trigger_name
on {table_name view_name}
{for After Instead of }
[ insert, update,delete ]
as
sql_statement
九:相关示例:
1:在Orders表中建立触发器﹐当向Orders表中插入一条订单记录时﹐检查goods表的货品状态status是否为1(正在整理)﹐是﹐则不能往Orders表加入该订单。
create trigger orderinsert
on orders
after insert
as
if (select status from goods,inserted
where goods.name=inserted.goodsname)=1
begin
print ‘the goods is being processed’
print ‘the order cannot be committed’
rollback transaction –回滚﹐避免加入
end
2:在Orders表建立一个插入触发器﹐在添加一条订单时﹐减少Goods表相应的货品记录中的库存。
create trigger orderinsert1
on orders
after insert
as
update goods set storage=storage-inserted.quantity
from goods,inserted
where
goods.name=inserted.goodsname
3:在Goods表建立删除触发器﹐实现Goods表和Orders表的级联删除。
create trigger goodsdelete
on goods
after delete
as
delete from orders
where goodsname in
(select name from deleted)
4:在Orders表建立一个更新触发器﹐监视Orders表的订单日期(OrderDate)列﹐使其不能手工修改.
create trigger orderdateupdate
on orders
after update
as
if update(orderdate)
begin
raiserror(‘ orderdate cannot be modified’,10,1)
rollback transaction
end
5:在Orders表建立一个插入触发器﹐保证向Orders表插入的货品名必须要在Goods表中一定存在。
create trigger orderinsert3
on orders
after insert
as
if (select count(*) from goods,inserted where goods.name=inserted.goodsname)=0
begin
print ‘ no entry in goods for this order’
rollback transaction
end
6：Orders表建立一个插入触发器，保证向Orders表插入的货品信息要在Order表中添加
alter trigger addOrder
on Orders
for insert
as
insert into Order
select inserted.Id, inserted.goodName,inserted.Number from inserted
You Are Not Google
作者 Ozan Onay ，译者 薛命灯 查看原文：You Are Not Google。
软件工程师总是着迷于荒唐古怪的事。我们看起来似乎很理性，但在面对技术选型时，总是陷入抓狂——从Hacker News到各种博客，像一只飞蛾一样，来回折腾，最后精疲力尽，无助地飞向一团亮光，跪倒在它的前面——那就是我们一直在寻找的东西。
真正理性的人不是这样做决定的。不过工程师一贯如此，比如决定是否使用MapReduce。
Joe Hellerstein在他的大学数据库教程视频中说道：
世界上只有差不多5个公司需要运行这么大规模的作业。至于其他公司……他们使用了所有的IO来实现不必要的容错。在2000年代，人们狂热地追随着Google：“我们要做Google做过的每一件事，因为我们也运行着世界上最大的互联网数据服务。”
超出实际需求的容错没有什么问题，但我们却为此付出了的惨重的代价：不仅增加了IO，还有可能让原先成熟的系统——包含了事务、索引和查询优化器——变得破碎不堪。这是一个多么严重的历史倒退！有多少个Hadoop用户是有意识地做出这种决定的？有多少人知道他们的决定到底是不是一个明智之举？
MapReduce已经成为一个众矢之的，那些盲目崇拜者也意识到事情不对劲。但这种情况却普遍存在：虽然你使用了大公司的技术，但你的情况却与他们大不一样，而且你的决定并没有经过深思熟虑，你只是习以为常地认为，模仿巨头公司就一定也能给你带来同样的财富。
是的，这又是一篇劝大家“不要盲目崇拜”的文章。不过这次我列出了一长串有用的清单，或许能够帮助你们做出更好的决定。
很酷的技术？UNPHAT
如果你还在使用Google搜索新技术来重建你的软件架构，那么我建议你不要再这么做了。相反，你可以考虑应用UNPHAT原则。
- 在彻底了解（Understand）你的问题之前，不要急着去寻找解决方案。你的目标应该是在问题领域内“解决”问题，而不是在方案领域内解决问题。
- 列出（eNumerate）多种方案，不要只把眼睛盯在你最喜欢的方案上。
- 选择一个候选方案，并阅读相关论文（Paper）。
- 了解候选方案的产生背景（Historical context）。
- 比较优点（Advantages）和缺点，扬长避短。
- 思考（Think）！冷静地思考候选方案是否适合用于解决你的问题。要出现怎样异常的情况才会让你改变注意？例如，数据要少到什么程度才会让你打消使用Hadoop的念头？
你不是Amazon
UNPHAT原则十分直截了当。最近我与一个公司有过一次对话，这个公司打算在一个读密集的系统里使用Cassandra，他们的数据是在夜间加载到系统里的。
他们阅读了Dynamo的相关论文，并且知道Cassandra是最接近Dynamo的一个产品。我们知道，这些分布式数据库优先保证写可用性（Amazon是不会让“添加到购物车”这种操作出现失败的）。为了达到这个目的，他们在一致性以及几乎所有在传统RDBMS中出现过的特性上做出了妥协。但这家公司其实没有必要优先考虑写可用性，因为他们每天只有一次写入操作，只是数据量比较大。
他们之所以考虑使用Cassandra，是因为PostgreSQL查询需要耗费几分钟的时间。他们认为是硬件的问题，经过排查，我们发现数据表里有5000万条数据，每条数据最多80个字节。如果从SSD上整块地读取所有数据大概需要5秒钟，这个不算快，但比起实际的查询，它要快上两个数量级。
我真的很想多问他们几个问题（了解问题！），在问题变得愈加严重时，我为他们准备了5个方案（列出多个候选方案！），不过很显然，Cassandra对于他们来说完全是一个错误的方案。他们只需要耐心地做一些调优，比如对部分数据重新建模，或许可以考虑使用（当然也有可能没有）其他技术……但一定不是这种写高可用的键值存储系统，Amazon当初创建Cassandra是用来解决他们的购物车问题的！
你不是LinkedIn
我发现一个学生创办的小公司居然在他们的系统里使用Kafka，这让我感到很惊讶。因为据我所知，他们每天只有很少的事务需要处理——最好的情况下，一天最多只有几百个。这样的吞吐量几乎可以直接记在记事本上。
Kafka被设计用于处理LinkedIn内部的吞吐量，那可是一个天文数字。即使是在几年前，这个数字已经达到了每天数万亿，在高峰时段每秒钟需要处理1000万个消息。不过Kafka也可以用于处理低吞吐量的负载，或许再低10个数量级？
或许工程师们在做决定时确实是基于他们的预期需求，并且也很了解Kafka的适用场景。但我猜测他们是抵挡不住社区对Kafka的追捧，并没有仔细想过Kafka是否适合他们。要知道，那可是10个数量级的差距！
再一次，你不是Amazon
比Amazon的分布式数据库更为著名的是它的可伸缩架构模式，也就是面向服务架构。Werner Vogels在2006年的一次访谈中指出，Amazon在2001年时就意识到他们的前端需要横向伸缩，而面向服务架构有助于他们实现前端伸缩。工程师们面面相觑，最后只有少数几个工程师着手去做这件事情，而几乎没有人愿意将他们的静态网页拆分成小型的服务。
不过Amazon还是决定向SOA转型，他们当时有7800个员工和30亿美元的销售规模。
当然，并不是说你也要等到有7800个员工的时候才能转向SOA……只是你要多想想，它真的能解决你的问题吗？你的问题的根源是什么？可以通过其他的方式解决它们吗？
如果你告诉我说，你那50个人的公司打算转向SOA，那么我不禁感到疑惑：为什么很多大型的公司仍然在乐此不彼地使用具有模块化的大型单体应用？
甚至Google也不是Google
使用Hadoop和Spark这样的大规模数据流引擎会非常有趣，但在很多情况下，传统的DBMS更适合当前的负载，有时候数据量小到可以直接放进内存。你是否愿意花10,000美金去购买1TB的内存？如果你有十亿个用户，每个用户仅能使用1KB的内存，所以你的投入远远不够。
或许你的负载大到需要把数据写回磁盘。那么你需要多少磁盘？你到底有多少数据量？Google之所以要创建GFS和MapReduce，是要解决整个Web的计算问题，比如重建整个Web的搜索索引。
或许你已经阅读过GFS和MapReduce的论文，Google的部分问题在于吞吐量，而不是容量，他们之所以需要分布式的存储，是因为从磁盘读取字节流要花费太多的时间。那么你在2017年需要使用多少设备吞吐量？你一定不需要像Google那么大的吞吐量，所以你可能会考虑使用更好的设备。如果都用上SSD会给你增加多少成本？
或许你还想要伸缩性。但你有仔细算过吗，你的数据增长速度会快过SSD降价的速度吗？在你的数据撑爆所有的机器之前，你的业务会有多少增长？截止2016年，Stack Exchange每天要处理2亿个请求，但是他们只用了4个SQL Server，一个用于Stack Overflow，一个用于其他用途，另外两个作为备份复本。
或许你在应用UNPHAT原则之后，仍然决定要使用Hadoop或Spark。或许你的决定是对的，但关键的是你要用对工具。Google非常明白这个道理，当他们意识到MapReduce不再适合用于构建索引之后，他们就不再使用它。
先了解你的问题
我所说的也不是什么新观点，不过或许UNPHAT对于你们来说已经足够了。如果你觉得还不够，可以听听Rich Hickey的演讲“吊床驱动开发”，或者看看Polya的书《How to Solve It》， 或者学习一下Hamming的课程“The Art of Doing Science and Engineering”。我恳请你们一定要多思考！在尝试解决问题之前先对它们有充分的了解。最后送上Polya的一个金句名言：
回答一个你不了解的问题是愚蠢的，到达一个你不期望的终点是悲哀的。
酷冷至尊 宏录制 设置
按FN+F11 设置宏，此时C灯亮，按下要设置的键，此时S灯亮，按下功能键比如回车此时G灯亮，按下scrlk，设置完成，只有C灯亮，如果我不想设置其他的能立马终止吗，还是必须得等它超时自动退出？ 删除时 CSD都亮，然后删除刚才的按键后也没有终止的键，智能到等他超时停止 结束录制宏的按键是FN+ESC，结束删除宏也是这个