Laravel模型默认使用时间戳以实现“约定优于配置”，自动记录数据的创建和更新时间，通过created_at和updated_at字段提供数据追踪能力。框架底层将时间戳存储为DATETIME或TIMESTAMP类型，并在模型中转换为Carbon实例，便于格式化和比较。可通过对模型设置$timestamps = false禁用此功能，或通过定义CREATED_AT和UPDATED_AT常量自定义字段名。访问时可直接使用Carbon方法进行时间处理。利用时间戳可实现基础审计、数据生命周期管理、缓存失效策略、报表分析及乐观锁辅助。常见误区包括使用查询构建器时updated_at不自动更新，规避方式是优先通过模型实例操作或手动设置时间字段；时区配置不一致可能导致时间显示错误，建议数据库和应用均使用UTC并在展示时转换；批量操作时时间戳更新可能带来性能开销，可通过withoutTimestamps()临时禁用。功能扩展包括使用软删除实现deleted_at字段，添加自定义时间字段如published_at并通过$casts转换为datetime，利用$touches属性在子模型更新时同步更新父模型时间戳，结合模型观察者监听时间变化触发日志、缓存清理等逻辑，或集成第三方包实现完整操作审计。
Laravel模型中的时间戳，本质上是数据库表里的
created_at
和
updated_at
两个字段，它们是框架为我们提供的一种自动化机制，用于记录数据记录的创建时间和最后修改时间。简单来说，它们是你的数据生命周期里，两个默默无闻但至关重要的时间标记。
解决方案
管理和使用Laravel模型的时间戳，通常涉及理解其默认行为、根据需求进行调整，以及在特定场景下进行干预。
默认情况下，当你创建一个新的模型实例并保存时，
created_at
和
updated_at
字段会被自动填充为当前时间。当你更新一个已存在的模型实例并保存时，
updated_at
字段会自动更新为当前时间。Laravel在底层会将这些时间戳存储为数据库的
DATETIME
或
TIMESTAMP
类型，并在你从模型中取出时，自动将其转换为
Carbon
实例，这是一个非常方便的日期时间处理库。
如果你不希望某个模型自动维护时间戳，可以在模型类中设置
public $timestamps = false;
。比如：
namespace AppModels;use IlluminateDatabaseEloquentModel;class Comment extends Model{ public $timestamps = false; // ...}
有时，你的数据库表可能使用了不同的时间戳字段名，比如
creation_date
和
last_modified_date
。你可以通过在模型中定义常量来覆盖默认的字段名：
namespace AppModels;use IlluminateDatabaseEloquentModel;class Article extends Model{ const CREATED_AT = 'creation_date'; const UPDATED_AT = 'last_modified_date'; // ...}
访问时间戳非常直接，由于它们被转换为
Carbon
实例，你可以使用
Carbon
提供的所有方法进行格式化、比较等操作：
$user = User::find(1);echo $user->created_at->format('Y-m-d H:i:s'); // 格式化输出echo $user->updated_at->diffForHumans(); // "5 minutes ago"
如果你需要在保存模型时临时禁用时间戳更新，例如在导入旧数据时想保留原始的
updated_at
，可以这样做：
$post = Post::find(1);$post->timestamps = false; // 禁用时间戳更新$post->title = '新的标题';$post->save();$post->timestamps = true; // 重新启用（如果后续还需要）
为什么Laravel模型默认使用时间戳，以及我该如何利用它进行数据追踪？
Laravel模型默认启用时间戳，这其实是框架设计哲学中“约定优于配置”的一个典型体现。从我的经验来看，这大大减少了我们在数据层面做审计和追踪的重复工作。想象一下，如果每次创建或更新数据，我们都得手动去设置
created_at
和
updated_at
字段，那代码会变得多么冗余和易错。框架替我们处理了这些细节，让我们能更专注于业务逻辑本身。
利用时间戳进行数据追踪，远不止看看数据是什么时候创建或修改的那么简单：
基础审计和调试： 当一个数据出现问题时，
created_at
和
updated_at
能迅速帮我们定位问题发生的大致时间窗口。比如，一个用户报告他的个人资料在某个时间点被错误修改了，我们就可以通过
updated_at
来缩小排查范围。数据生命周期管理： 很多业务场景需要根据数据的“新鲜度”来做决策。例如，一个订单如果在创建后24小时内未支付，就自动取消；一个通知在
created_at
一周后自动过期。时间戳是实现这些逻辑的基石。缓存策略优化： 这是一个非常实用的技巧。当一个模型被更新时，它的
updated_at
会随之改变。我们可以利用这个变化来智能地使相关的缓存失效。比如，一个文章详情页的缓存，可以将其缓存键与文章的
updated_at
绑定。一旦文章更新，
updated_at
变了，缓存键也就变了，旧的缓存自然失效，避免了手动清除缓存的麻烦。报表和分析： 想知道每天有多少新用户注册？每月有多少商品被更新？时间戳提供了最直接的数据源，配合数据库的聚合函数，可以轻松生成各种时间序列的报告，帮助我们洞察业务趋势。乐观锁的辅助： 虽然不是一个完整的乐观锁方案，但在一些简单场景下，可以利用
updated_at
作为版本号。在更新数据前，先读取当前的
updated_at
，更新时带上这个值作为条件。如果更新失败（说明
updated_at
已经变了），则表示数据已被其他进程修改，从而避免并发冲突。
在实际开发中，时间戳管理有哪些常见的“坑”或误区？如何规避？
尽管Laravel的时间戳机制非常方便，但在实际开发中，我确实遇到过一些让人头疼的“坑”，或者说是一些容易被忽略的细节。
一个最常见的误区，也是初学者经常会踩的坑，就是使用查询构建器（Query Builder）进行更新操作时，
updated_at
不会自动更新。当你直接使用
DB::table('users')->where('id', 1)->update(['name' => 'New Name']);
这样的语句时，Laravel的模型事件并不会被触发，因此
updated_at
字段也就不会自动更新。我曾经就因为这个，导致一些依赖
updated_at
的缓存策略失效，排查了好一阵子。
规避方法： 除非你明确知道自己在做什么，并且不需要
updated_at
更新，否则请始终通过模型实例进行更新操作。例如：
$user = User::find(1);$user->name = '新的名字';$user->save(); // 此时 updated_at 会自动更新
如果你确实需要使用查询构建器，但又想更新
updated_at
，那么你需要手动将其加入更新数组：
DB::table('users')->where('id', 1)->update([ 'name' => 'New Name', 'updated_at' => now(), // 手动设置]);
第二个“坑”是时区问题。数据库通常会存储UTC时间，而你的应用可能在
config/app.php
中设置了本地时区。Laravel在将数据库中的时间戳转换为
Carbon
实例时，会根据你的应用时区进行调整。如果你的数据库和应用时区配置不一致，或者在不同服务之间传递时间戳时没有注意时区转换，就可能导致时间显示混乱。比如，你看到的时间比实际时间晚了8小时，或者早了8小时。
规避方法： 最佳实践是让数据库和应用都使用UTC时间存储和处理。在
config/app.php
中将
timezone
设置为
'UTC'
，并在前端展示时，再根据用户的时区偏好进行转换。
Carbon
实例本身是时区感知的，它能很好地处理这些转换。
// config/app.php'timezone' => 'UTC',
第三个可能遇到的问题是，在进行大量数据导入或批量操作时，时间戳的自动更新可能会带来额外的性能开销。虽然对于大多数应用来说，这种开销可以忽略不计，但如果你正在处理百万级别的数据，每次保存都触发时间戳更新和相关事件，可能会拖慢进程。
规避方法： 在这种极端情况下，你可以考虑暂时禁用时间戳，或者使用原始SQL语句进行批量操作，并在操作完成后，手动更新相关记录的
updated_at
字段（如果需要）。
// 临时禁用时间戳Model::withoutTimestamps(function () use ($data) { foreach ($data as $item) { // 创建或更新模型，此时时间戳不会自动更新 MyModel::create($item); }});
除了
created_at
和
updated_at
，我还能如何扩展Laravel的时间戳功能，以满足更复杂的业务需求？
created_at
和
updated_at
固然强大，但在许多复杂的业务场景中，它们可能无法完全满足我们的需求。幸运的是，Laravel提供了一系列灵活的机制，让我们能够轻松地扩展和定制时间戳功能。
一个最直接且内置的扩展就是软删除（Soft Deletes）。当我们需要“删除”一条数据，但又不想真正从数据库中移除它时，软删除就派上用场了。它通过在模型中添加一个
deleted_at
字段来实现。当调用
delete()
方法时，Laravel不会真正删除记录，而是将
deleted_at
字段设置为当前时间。被软删除的记录在常规查询中是不可见的，但你可以通过
withTrashed()
或
onlyTrashed()
方法来检索它们。
要使用软删除，只需在模型中引入
SoftDeletes
Trait：
namespace AppModels;use IlluminateDatabaseEloquentModel;use IlluminateDatabaseEloquentSoftDeletes; // 引入 Traitclass Post extends Model{ use SoftDeletes; // 使用 Trait // ...}
然后在数据库迁移中添加
deleted_at
字段：
Schema::table('posts', function (Blueprint $table) { $table->softDeletes(); // 添加 deleted_at 字段});
除了软删除，我们还可以添加自定义的时间戳字段来追踪更具体的业务状态。例如，一个文章模型可能需要一个
published_at
字段来记录文章的发布时间，一个订单模型可能需要
paid_at
和
shipped_at
来记录支付和发货时间。
在数据库迁移中添加这些字段：
Schema::table('articles', function (Blueprint $table) { $table->timestamp('published_at')->nullable(); // 可空的时间戳});
在模型中，为了让Laravel自动将这些字段转换为
Carbon
实例，我们需要在
$casts
属性中声明它们：
namespace AppModels;use IlluminateDatabaseEloquentModel;class Article extends Model{ protected $casts = [ 'published_at' => 'datetime', ]; // ...}
这样，你就可以像操作
created_at
一样操作
published_at
了：
$article = Article::find(1);$article->published_at = now();$article->save();
另一个非常实用的功能是“触摸”父级时间戳（Touching Parent Timestamps）。假设你有一个
Post
模型和多个
Comment
模型，当一个评论被更新时，你可能希望关联的文章的
updated_at
字段也随之更新，这样可以方便地知道哪些文章有新的活动。你可以在子模型中定义
$touches
属性来实现：
namespace AppModels;use IlluminateDatabaseEloquentModel;class Comment extends Model{ protected $touches = ['post']; // 当 Comment 更新时，关联的 Post 的 updated_at 也会更新 public function post() { return $this->belongsTo(Post::class); }}
对于更复杂的逻辑，比如在某个时间戳更新时触发特定的业务流程，或者需要记录更详细的历史版本，模型观察者（Model Observers）和事件（Events）是强大的工具。你可以在
updating
、
saved
等模型事件中监听时间戳的变化，然后执行自定义逻辑。例如，当一个
User
的
updated_at
改变时，你可以触发一个事件，通知缓存系统清除相关用户的缓存，或者记录到审计日志中。
// UserObserver.phpnamespace AppObservers;use AppModelsUser;class UserObserver{ public function updated(User $user) { // 只有当 updated_at 字段实际改变时才执行逻辑 if ($user->isDirty('updated_at')) { // 记录日志，或者触发其他业务逻辑 Log::info("用户 {$user->id} 的信息在 {$user->updated_at} 被更新了。"); } }}
最后，如果你的需求是完整的版本控制或操作历史记录，那么仅仅依赖时间戳可能就不够了。这时，你可以考虑使用专门的包（如
spatie/laravel-activitylog
或
owen-oj/laravel-auditing
），或者自己构建一个
history
表，通过模型事件将每次重要的模型变更（包括时间戳变化）记录下来，形成一个完整的操作链。时间戳在这里就成为了触发这些更深层次追踪机制的信号。
以上就是Laravel模型时间戳？时间戳怎样管理使用？的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/199235.html
微信扫一扫 
支付宝扫一扫 
