某大厂程序员女友在网上高调晒男友工牌和收入，宣称年薪高达300万 没想到被其男友同事认出身份，随后在内网进行了举报～

刚刷到个贴子，说深圳大厂一程序员年薪300万，结果女友在网上晒工牌炫富，被同事认出来举报，最后直接被辞退了 。

我觉得这事吧，从程序员角度看真是教训深刻。程序员的身份和公司项目往往自带保密属性，你工资再高，写的代码再牛，一旦触碰到公司底线，那就是“一票否决”。网友里有人骂女友不懂分寸，也有人替程序员惋惜，但归根到底，职场最怕的不是能力不行，而是风险意识太弱。

换个角度想，咱们天天写代码，注重权限控制、信息加密，但生活里却常常忽略了“隐私安全”这个需求。你以为只是秀优越感，但在别人眼里可能是泄密风险，公司立场自然不会含糊。

总的来说，程序员还是要记住，代码写得稳是一回事，职业操守和风险意识才是立身之本。钱可以再赚，口碑和机会可别轻易丢了。【备注:文末可领最新资料】

面试题：最低票价

昨晚十一点多在地铁上补票……啊不是，补题。手机电量只剩 5%，我就想着先把这道“最低票价”搞定，你们也知道吧，出行那点事，买 1 天、7 天、30 天通票，到底怎么买最省钱，这不就动态规划的典型味儿嘛。

给你一串出行的日期 days，比如 [1,4,6,7,8,20]，再给三种票的价格 costs=[c1,c7,c30]。某天你要出门就得保证那天在一张有效票的覆盖期里。问最少花多少钱。就这样，没坑，边界也就是第一天到最后一天那段区间。

思路别拧巴：按天推进

很多人会盯着 days 下标转，当然也能做。我更喜欢“日历表”法：从 day=1 一直推到最后一天 last。dp[d] 表示从第 1 天到第 d 天的最小花费。当天不是出行日？那就继承昨天：dp[d]=dp[d-1]。如果是出行日，得买票，三张里挑便宜的结果：

• 买 1 天票：dp[d-1]+c1
• 买 7 天票：dp[max(0,d-7)]+c7
• 买 30 天票：dp[max(0,d-30)]+c30 注意那两个 max(0, …)，开头几天别越界。为了 O(1) 判断“今天是不是出行日”，把 days 放到一个 set 里就很顺手。

from typing import List

defmincostTickets(days: List[int], costs: List[int]) -> int:
ifnot days:
return0
    last = days[-1]
    travel = set(days)
    c1, c7, c30 = costs
    dp = [0] * (last + 1)
for d in range(1, last + 1):
if d notin travel:
            dp[d] = dp[d - 1]
continue
        one = dp[d - 1] + c1
        seven = dp[max(0, d - 7)] + c7
        thirty = dp[max(0, d - 30)] + c30
        dp[d] = min(one, seven, thirty)
return dp[last]

# 小测一下
print(mincostTickets([1,4,6,7,8,20], [2,7,15]))  # 11

复杂度和边界我都说两句

时间 O(last_day)，空间 O(last_day)。如果 days 间隔特大、last 很大，担心浪费？可以换成“按出行天索引递归 + 记忆化”的写法，复杂度 O(len(days))，空间 O(len(days))，思路是对每个出行日尝试三张票，跳到能覆盖的下一个出行日索引。一般面试现场，日历 DP 已经够稳。

价格分布有时候会“反直觉”，比如 7 天票贵但刚好卡住密集出行，那它还是划算；代码里别贪心地看到“今天就买 1 日”就收手，三种都得比一下。还有就是 set 判天这步非常省事，别每次 in days 线性找，浪费功夫。